On 11/11/08, Jay Pipes <[EMAIL PROTECTED]> wrote: > > > 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.
I agree with the sentiment of storing BLOBs in the DB is a bad architectural design. Also, in answer to the question of "how big is something before it becomes a BLOB", in MySQL you can have TINYBLOB, which has a limit of 255 bytes. The point of using TINYBLOB versus VARCHAR in that case is (in my opinion) the fact that MySQL allocates a separate object for a BLOB. How hard would it be to, instead of allocating a separate object, having a plugin interface there? That way you could have MySQL's way of allocating a separate object, or you could stick some kind of filesystem plugin in there (2 kinds -- store a file on the system that others can use normally (ie, picture.jpg) and have a file-handle link automatically in the db, or just save a big blob to a non-usable or non-visible file to be used only by the database)... and in that case, there could also be plugins to Lucene and Sphinx, using their indexing for blobs. It's not as simple as I made it sound above, but I'm sure it's doable, and I think it's worth investing the time, as it would be great to have some kind of way to "look at all the stuff in this directory [recursively or not] and make a table out of it, including some metadata". In the same way CSV is neat that way. -Sheeri
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
