Scott Hess wrote:
>
> Miso Pach <miso@stripped> wrote:
> > On Mon, 26 Jul 1999, Sasha Pachev wrote:
> > > MySQL relies on the filesystem to store the data. It would be rather
> > > wasteful to use it store large chunks of data that does not need to be
> > > orginized or searched in any particular fashion - you can get the same
> > > from the filesystem without the SQL overhead.
> >
> > Is this true? Everybody who stores something binary in a
> > database is planning on some searching right? By na ID,
> > annotation etc.. mysql engine is much better and faster in
> > locating the chung of data than say a filesystem. Say you
> > need to store 10,000 GIFs (size of 3KB each) in a table. It
> > makes me think that mysql is the solution. Am I wrong?
>
> You only really need the data in MYSQL if you are going to do queries on the
> contents. If you're just going to say "Give me the BLOB with id 5693", then
> the differences between filesystem and database storage become important -
> because it's trivially easy to build a filesystem structure which returns
> the file with id 5693!
>
> At 3KB, with images that seldom change (less than once per week, say), with
> under perhaps 100,000 images, I'd probably not hesitate to use blobs. I
> might make arrangements to protect from fragmentation, though, say by
> forcing the blobs to always be larger than my largest image (which only
> works if you can limit the image sizes drastically). If the images were
> going to vary between 3KB and 100KB, and were going to change a couple times
> a day, then it's likely that you would start to have problems with blobs due
> to fragmentation.
>
> Of course, the most used filesystems in the world fragment as badly or worse
> than MYSQL :-).
>
But then you have to deal with double fragmentation - the one from
MySQL, and the one from the filesystem itself.
--
Sasha Pachev
http://www.sashanet.com/ (home)
http://www.direct1.com/ (work)
