At 4:28 PM -0400 8/18/99, Urb LeJeune wrote:
>>> > Why? increadable waste of space and performance destroyer.
>>> >Why not just store a link?
>>>
>>> As for wasting space, every file in a file system has wasted space,
>>> unless it exactly fills up the last block allocated to it. Why would
>>> MySQL be worse than the file system?
>
> You're correct, it has to be stored somewhere, but store it
>somewhere when
>its mere size doesn't degrade the performance of your DB. Let's assume that
>every row in your table averages a 60K gif. That's 60k the gets moved
>around almost every time you do a query, dump a table, etc. In addition,
>what do get from that field when you query it? Nothing iseful unless you
>take the gif and display it. On the other hand, if you use meaningful names
>like abc_co_logo.gif, you know exactly
>what it contains.
Thanks for your message, that's the kind of thing I was wondering about.
But let me play devil's advocate.
The size of the gif doesn't degrade the performance of the file system,
that's true, but the number of gif files does. As you add gif files to
the file system, your lookup time increases, perhaps linearly depending
on how you arrange them in the file system and the intelligence of the
directory lookup routines. This is not true when you're looking up images
in the database.
I don't understand why the 60K gets moved each time you do a query, unless
you select the field in which the gif is stored. And you wouldn't do that
unless you wanted to do something with it, so you'd need to move that 60K
anyway. Am I missing something here?
The 60K gets moved when you dump a table, true. But it also gets
moved when you
dump your file system, if the image is stored in a file.
As far as using meaningful names, there's nothing to stop you from storing
a meaningful name in the database rather than (or maybe in addition to)
a meaningless identification number.
> You also create a maintenance nightmare. How do you handle a
>changed gif?
>You have to upload it to your system, modify your table and get rid of the
>upoladed gif. If you only have a pointer and keep the same name, nothing
>has changes as far as the DB is concerned.
Isn't the maintenance nightmare primarily a function of the method you use
to update the gif? What's to stop me from having a simple DBI script that
I can run on my client host that shoves the new gif across the wire in a query
that updates the table directly? No need to upload the file, then get rid of
it after the update.
--
Paul DuBois, paul@stripped
