RE: Why does this work on one server...(Final comment)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard:

I'm not arguing with you, I just want to understand the problem and solution.

I said:

 > For storing an image into MySQL I simply used:

 > $image_large = mysql_real_escape_string($buffer);

 Then for displaying the image, I use:

 if (get_magic_quotes_gpc())
	{
	$fileContent = stripslashes($fileContent);
	}

You said:

This is bass-ackwards...

What you've done is store the data with "double" addslashes() when
MagicQuotes are on, and then you "undo" one of them.

So your data actually in the database has an extra set of slashes on it.

That's not good clean data.

If I perform stripslashes first, then the process doesn't work.

Furthermore, according to:

http://us3.php.net/mysql_real_escape_string

This function must always (with few exceptions) be used to make data safe before sending a query to MySQL.

As such, I used escape_string before the query. Is mine one of those exceptions?

----

You said:

Stop confusing the hell out of yourself, and use .htaccess to turn
magic_quotes OFF and magic_quotes_runtime OFF!!!

Great idea -- I will do -- I just wanted to understand the problem.

----

You also said:

Another thought he'll have to face eventually, on this insane path of
JPEG in database storage:

What size buffer does PHP <-> MySQL have?

If your JPEG is too big, ka-boom.

Actually, it's more like "silently discard the tail end of my larger
JPEGs, and some images are broken, but it works for small images, what
did I do wrong?"

I've had that happen (half image thing). The solution is to load the image into tmp directory, which is done anyway, and then reduce the image to the size(s) you want before storing it into MySQL.

-----

You also said:

You really should consider using a highly-optimized large-sized-data
custom piece of wonderful software that's really MUCH better for
storing, managing, and retrieving JPEGs than MySQL...

It's called:  "the file system"

You're almost for sure NOT using any real MySQL features on your JPEG
data.  It's not indexed for speed of retrieval based on raw bytes.
It's not something you're going to search through the raw bytes for
eye color.  MySQL will RARELY (and only for tiny files) be any faster
than the file system for retrieval.  So you're just clogging up your
database with this massive chunk of data for no real reason.

I'm aware of the file system, I've used it a couple of times in my life.

Storing things in MySQL should not be based upon "If you're going to search the field or not". MySQL storage is simply a way to store stuff. It's not that much different than storing things on the "file system" because all you're storing is 1's and 0's anyway, right? It should not make any difference if file's 1's and 0's are stored on a file system's hard drive or the files 1's and 0's are stored in a MySQL dB, which is also stored on a hard drive, right?

Remember, the only difference here is the overhead architecture of how to access the data -- there are no differences between 1's and 0's depending on where they are stored on a hard drive.

Now, one can argue that the time it takes to pull an image from MySQL is different than from the file system, I've experienced that, and it's important to me, and I will be changing my method to the file system.

However, using MySQL for storing things does present some advantages -- like associating related but different data types together data in one record (it's hard to do that using a file system); moving data from one server to another (again, it's hard to do that with a file system); easier record keeping and editing; and if my memory serves me right (which may be in error), there is a limit to the number of records you can have in a directory whereas that isn't so in MySQL (memory permitting of course).

-----

You also said:

You'll then need to start messing with BLOB data fields and
special-handling.

If what you mean in "special-handling" is what I've experienced here, then I have to agree with you. However, all data types require some form of "special-handling" it's just that BLOB's are not as well understood IMO. My post to this list and the assorted answers I received is an example of this.

For example, if I had posted "How do you store strings in MySQL?" then I would guess that all the answers would have been the same. But when I ask about BLOB's, I received an assortment of answers -- so apparently, there is confusion on this list as well.

----

You also said:

Again I say, just put the damn files in the file system where they
belong.

An opinion (see below).

----

You also said:

We've been through this whole scenario on this list SOOOO many times
it's frightening! :-)

It's like watching the same episode of Twilight Zone over and over and
over.  And not a good episode, either. :-)

Interesting you should say that -- Dennis Weaver appeared in a Twilight Zone episode where he was a prisoner who was executed over and over. Each time during the courtroom trial he tried to get someone to believe him and delay the execution -- but unfortunately, the Governor would always call too late with a stay of execution.

Because this scenario has been raised sooooo many times, there might be something more to it (see blow). <Awaiting a call from the Governor>.

----

You also said:

For that matter, stop trying to cram your JPEGs into your database in
the first place, and you'll also be a lot less frustrated.

"Frustrated" is a byproduct of my profession and is usually inversely proportional to talent. But, In my case, lacking talent and compensating with hard work, is the way I learn.

Thus far, as I said before, the only difference *I* have experienced in storing images in a dB rather than in a file system is the time it takes to retrieve and display an image in a web page. Unfortunately, pulling an image from a dB does take longer and I'm now forced to switch from using BLOB's to url's.

However, all the other concerns I've heard against using BLOB's thus far have not been accurate IMO. There are a lot of misconceptions, even published in respectable books, as to why one should not use BLOB's. But, I personally think that it's problems like what I've experienced here, which has nothing to do with BLOB's, that lead to apprehension about their use.

No offense to anyone, but I claim that if you don't really know what the actual limitations and advantages of something are, then you are the one who is limited and at a disadvantage.

tedd

As my grandson once said "There are 10 types of people in the world -- those who understand binary and those who do not."
--
--------------------------------------------------------------------------------
http://sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux