Wow,
I turn away from my mail for a day or two and come back to find a deluge
of all these passionate emails and fervor. You'd think this was a
discussion on religion or politics. I suppose in a sense it is.
That's the worst thing about writing a book is that I often miss these
discussions!
Jim, if you had a magic wand, what would be the best way to store
BLOBs-- say if you were to be writing a DB app from scratch-- vs. the
way it is now implemented (pointer in server record) ? What is the
"right" way, and how do you deal with all the issues that people bring
up such as backup, etc, that you contend are issues only because they
were implemented wrongly in the first place?
I sometimes wonder about the issue of whether your (one's) RDBMS is
good, it should eat it's own dogfood by using itself for it's own
information as is the case with information schema. The age-old question
of whether to store BLOBs in the DB or not seems to be in this category
of philosophical arguments.
--Patrick
Jim Starkey wrote:
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!
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
