[GLLUG] BLOBs in Databases

Bryan Laur bjlaur at mtu.edu
Mon Feb 2 20:07:09 EST 2015


I wasn't going to reply, but since Rick and Jason have, I thought I'd throw
my hat into the ring as well. It's kind of interesting because we're each
professionals that see this from a different perspective.

First, BLOBs in traditional rdbms' are pretty much a terrible idea. Jason
suggests we should only use them when forced to, but I would argue there is
no case where we're legitimately forced to store anything as a BLOB in the
database. It's really just a bad idea for a number of reasons. The reason
that BLOBs in RDBMS' get used is because the database is already available,
developers depend on ACID compliance, and everyone is too cheap to come up
with a better solution when this one is readily available.

So, why do they even exists? Well sometimes there is a legitimate reason to
do something bad. If you're only going to store 1000 rows of BLOBs in the
database then while not ideal, it's not really going to cause much pain.
The problem comes along when it's decided to instead store hundreds of
thousands of these records, and they become largely unmanageable. It seems
to be far too easy to fall into this trap.

As Rick suggests, I think it's an even worse idea to write to file systems
directly without an abstraction layer. We have so many tools for managing
data, why would we ever consider trying to manage it directly ourselves?
 (I know that a file system itself is an abstraction layer on it's own, and
possibly we can put the required features below that abstraction layer, but
this solution doesn't seem ideal to me.)

Although I don't have much experience for this situation. (Or at least
doing the correct thing in this situation.), my suggestion of choice would
be to use something like mongodb GridFS. It seems to be the best of both
worlds as long as you can do without ACID compliance... and I think you can.

-Bryan



On Mon, Feb 2, 2015 at 7:10 PM, Richard Houser <rick at divinesymphony.net>
wrote:

> Application Environments like Java Enterprise Edition explicitly forbid
> accessing files directly from the filesystem.  Doing so usually just
> creates a giant mess and applications that don't scale correctly.  It's one
> of the banes JEE admins have to deal with with all the proprietary/broken
> apps.  I'm sure other environments have similar constraints on bypassing
> declared abstractions layers and hitting things directly.  By using
> database nuetral SQL through a suitable layer (JDBC Datasource, etc.), you
> can do things like take your SQLite application and spread it out into a
> horizontal cluster of PostgreSQL backends, etc.  If you hit those resources
> directly bypassing all the abstraction layers, you tend to make things
> really, really difficult for any admins trying to work with your app.  Now,
> that's not to say you can't create a resource wrapper of some sort that
> internally just stores the content on filesystems, handles replication,
> etc., but the point is that component can be independently swapped out,l
> moved around, tec.
>
> On Mon, Feb 2, 2015 at 2:17 PM, Chick Tower <c.e.tower at gmail.com> wrote:
>
>> I've been doing a little research into SQLite, and they have a storage
>> class (they say it's slightly more general than a datatype) for binary
>> large objects (BLOB).  You can store photo images, or I suppose even
>> executables, in the database.  (I assume the same is true for other
>> databases.)  My question is why?  You can't view an image with SQLite. How
>> do you even get an image out of a database to view it?
>>
>> Perhaps I'm wrong in the intended use of the BLOB storage class.  It says
>> on the SQLite website "The value is a blob of data, stored exactly as it
>> was input."  So maybe it's intended for something other than images, but,
>> if so, what?  I still wonder how you extract a BLOB from a database in
>> order to do anything with it.  Does anyone know what to do with BLOBs?
>> --
>>
>>                                Chick
>> _______________________________________________
>> linux-user mailing list
>> linux-user at egr.msu.edu
>> http://mailman.egr.msu.edu/mailman/listinfo/linux-user
>>
>
>
> _______________________________________________
> linux-user mailing list
> linux-user at egr.msu.edu
> http://mailman.egr.msu.edu/mailman/listinfo/linux-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.egr.msu.edu/mailman/public/linux-user/attachments/20150202/8f2440c3/attachment.html>


More information about the linux-user mailing list