<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>-Bryan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 7:10 PM, Richard Houser <span dir="ltr"><<a href="mailto:rick@divinesymphony.net" target="_blank">rick@divinesymphony.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 2:17 PM, Chick Tower <span dir="ltr"><<a href="mailto:c.e.tower@gmail.com" target="_blank">c.e.tower@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
<br>
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?<span><font color="#888888"><br>
-- <br>
<br>
Chick<br>
______________________________<u></u>_________________<br>
linux-user mailing list<br>
<a href="mailto:linux-user@egr.msu.edu" target="_blank">linux-user@egr.msu.edu</a><br>
<a href="http://mailman.egr.msu.edu/mailman/listinfo/linux-user" target="_blank">http://mailman.egr.msu.edu/<u></u>mailman/listinfo/linux-user</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
linux-user mailing list<br>
<a href="mailto:linux-user@egr.msu.edu">linux-user@egr.msu.edu</a><br>
<a href="http://mailman.egr.msu.edu/mailman/listinfo/linux-user" target="_blank">http://mailman.egr.msu.edu/mailman/listinfo/linux-user</a><br>
<br></blockquote></div><br></div>