Hacker News Reader

Comment by Spooky23 | Hacker News Reader

I've always pushed back at storing blob data in databases in most cases -- probably 80-90% of the time depending on the job.

Why? Databases are all about storing data in a structure defined by the relationships between the records. In most cases with files, the relevant data is the metadata or other structured data, not the file.

If you do the math, it's rarely cost effective to store unstructured data in a structured database. Databases are always harder to scale.

On the file side, there are dozens of ways to effectively deliver files that are cheaper, more scalable and simpler for many use cases.

View on HN

Databases also have advantages: transactions, durable logging, replication, integrated backups, etc.

Tom Kyte has some insightful points in this thread: https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUE...

"Do I want you to keep MY medical stuff in a directory, unsecured, unmanaged, not backed up like the database is - we have no idea if recovery is possible, who accessed it last? Who has access to it."

"if this data is valuable to your business, if this data is necessary for your business, if the loss of this data would damage your ability to do business - it has no business NOT being in the database."

Absolutely. I didn't say never do it... just that it doesn't make sense to me most of the time.

Tom is Mr. Oracle, so I am not shocked that he's a big advocate of using that platform. But I don't like the straw man argument that anything that isn't managed by an Oracle DBA is automatically flawed and unreliable. Give me a break... Robust auditing, backup, professional management, etc can be delivered anywhere. (Or f'ed up on an Oracle platform)

That said, it's a business decision -- somebody, somewhere has probably justified putting user home directories on an Oracle database.

Actually yeah I do want to keep MY medial stuff in a directory ; but that doesn't mean that it's unsecured, unmanaged and not backed up. Ultimately all data ends up on the filesystem in one way or another if it's large enough. I would rather have a filesystem that I can trust rather than trying to fix/ignore that layer by building more layers on top of it.

Relatational databases has their advantages compared with hierarchical filesystems of blobs, but that comment is really completely beside the point.

File systems are simpler and backups and replication are really much more straightforward. As anyone who did disaster recovery of Oracle databases can attest to, there are a lot of details to get wrong.

It boils down to what data you want to store and what your access patterns look like.

You don't get to avoid backing up the database just because your file contents happen not to be in it. Now you have two different backup jobs not just to run, but to run atomically.

Great point -- Oracle has a solid capability that is easy to operationally screw up. Database recovery is usually a real shitshow.

When you go to other platforms, you need solid process AND deep exterior in whether the database can do what you want. Can MySQL handle the same recovery scenarios that Oracle can? With which storage engines?

Reply on news.ycombinator.com