RE: [PHP] Why does this work on one server...(Final comment)
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 S 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
Re: [PHP] Why does this work on one server...(Final comment)
On 24/03/06, tedd [EMAIL PROTECTED] wrote: 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). The technical limit per directory in ReiserFS is slightly more than half a billion files. Although with the standard hashing function the practical limit is about 1.2 million. Would you like to hazard a guess about MySQL's performance with 1.2 million images in the same file? MySQL stores each table in it's own file which is subject to the filesystem size limits. For example the maximum file size in ReiserFS 3.5 is 2 Gig. So ignoring all the overheads, to fit more than 1.2 million images in a table, they'd have to average rather less than 2kb in size. Each of these images is likely to be a different size so you're stuck with variable length records, which has a significant performance impact in MySQL. It'll also result in gaps in the file which will further restrict the amount you can get in there. You'd better make sure your indexing on the table is good, because a sequential scan over that amount of data will give your disk IO a good workout. If you'd kept all your files in the filesystem you'd be able to leverage all the efficient tools honed over the years to manipulate them, and copying them to another server would involve just a simple rsync. If you need to associate the files with a particular record, all you need to do is store the filename. It's not rocket science. At the physical level, you're correct; It's all just binary data. At every other level there's a big difference between using the filesystem directly and bunging everything in MySQL. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why does this work on one server...(Final comment)
If I perform stripslashes first, then the process doesn't work. I usually raise eyebrows with this statement, but you should never (with very, very few exceptions) need to unescape anything. Ever. Richard was pointing out that the only reason you would need to strip slashes after retrieving data from the database is if you escaped it twice before putting it in there. If you're only escaping it once, which you seem to be claiming, then you should not have to unescape anything. Hope that helps. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why does this work on one server...(Final comment)
tedd wrote: I usually raise eyebrows with this statement, but you should never (with very, very few exceptions) need to unescape anything. Ever. What's this then? http://us3.php.net/mysql_real_escape_string That's an escaping function. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why does this work on one server...(Final comment)
tedd wrote: I usually raise eyebrows with this statement, but you should never (with very, very few exceptions) need to unescape anything. Ever. What's this then? http://us3.php.net/mysql_real_escape_string That's an escaping function. Chris A, it pays to read. Thanks -- it's been a long day. Now that I'm turning off register_globals and magic_quotes, I'm now trying to figure out why some of my scripts aren't working. tedd -- http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
