Jay Pipes wrote:
Jim Starkey wrote:
Ask Bjørn Hansen wrote:
On Nov 9, 2008, at 14:27, Jim Starkey wrote:
Even if it is inconvenient, it is the way to go. Why send a 50MB PDF
to the client if the client isn't going to actually request it?
What's the real use case for that? If you don't want it, just don't
ask for it - no?
First, the storage engine always has to materialize the blob, even if
the record is part of an exhaustive scan and is rejected.
The better solution is to not store the blob in the database, IMHO.
Store the metadata about the blob, but not the blob. Use the filesystem
for what it was intended. Sure, it may make backups slightly more
complex, since you need to back up the filesystem and the database for
critical data, but this is a minor inconvenience.
That's a terrible idea. It was a terrible idea in 1983 when it was
first raised by the DEC Rdb/VMS guys, and it's a worse idea today.
The application is talking to a SQL database. It doesn't know or care
where the database is. How is it going to know where to fetch the
blob? How is security supposed to work? How is backup supposed to
work? How is replication supposed to work?
Why are big things different from small things? Why use a database to
keep track of rows when a simple file will suffice?
Data is data. All data should be subject to the same availability,
consistency, and durability constraints.
Yes, big objects needs more intelligent handling because small
inefficiencies get magnified thousands of times over. But this is not
an argument against big objects, it is an argument for intelligent
handling of big objects.
The MySQL conception of a blob (a pointer embedded in a server record)
was moronic on the day it was invented. It hasn't gotten any better in
the intervening years.
I think your argument is basically this: We shouldn't improve blob
handling because the original implementation was so moronic as to be
useless for large blobs.
Well, duh.
(Incidentally, the DEC guys who argued against blobs where the same ones
who argued against relational databases. Real men, they believed, used
CODASYL databases.)
Second, the
program logic may look at non-blob fields to decide whether or not to
fetch the blob. For example, both a PDF and HTML translation may be
stored, but not all records have HTML translations. So the program
selects both and decides on a case by case basis.
At least with InnoDB - IIRC - then you don't even get the page cache
hit from the data then.
And really - in what kind of application is storing that big blobs a
good idea?[1]
All modern applications has jpegs and pdfs. It's part of the
environment. Some applications even use Word for textual data entry
because that's what 99% of the world uses. The minimum pdf is about
50K. The minimum Word document is about 40K. Pdfs produced by crappola
scanners are more like 500K. Jpegs by modern cameras are 1 - 2MB.
These are bad ideas only if the database is wretched at storing blobs.
I see your point, but I also don't see the point of prioritizing the
performance of blob storage over other things. IMHO, storing BLOBs in
the DB is bad architectural design. We shouldn't focus efforts on
optimizing for poor application design.
Your reasoning is both circular and wrong. Using a database system for
consistent and reliable data storage is an excellent application design,
one that we need to foster. Deciding that some data is less worthy than
others makes no sense at all.
Case in point -- an application to import the contents of a cell phone
into a database. Are you going to argue that the database is OK for the
phone book, call history, and text messages but photographs have to be
stored somewhere else? And a somewhere else subject to different
security, backup, and administration policies? And this is somehow
supposed to represent "good" application design?
A single JPEG is worth a thousand words (and a million precious
three-byte binary words).
Grumph!
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
