1. 10
  1. 7

    How strongly I disagree with “isolate applications” depends a lot on the definition of “application.” If we’re taking about a mail application and a shop, yes, they probably shouldn’t be peeking at each others tables. I’m less keen on slicing up applications into networked components without a really good reason.

    In my career I have been more concerned with developers over-cleaving than not cleaving enough, because I have seen it cause more problems that it solves. You are opting in to a distributed system, and distributed systems are hard.

    The choice is also not between a distributed system and a big ball of mud database. It is possible to have a database with a tasteful API and appropriate access controls. That’s the solution I would reach for before the cleaver.

    1. 3

      As a sysadmin, One of the biggest problems with doing the recommended course of action in this article is unaware and unintentional data loss.

      So, lets say everything is in the DB. You put pics in there, use imagemagick to shronk and store those in the DB. Your DB is getting stupidly large, because it’s not meant for binary blob data.

      So, you yoink out the binary data. Those images are now saved in /opt/datastore/…. instead of postgres DBdirs.

      The problem, that I’ve come across, is even though the DB is backed up in various ways, the backing up of the image dir path may not be (or be at different/bad backup periods).

      Another problem is syncing problems… So when you save picture/document/binary content, you’re goinig to hash it and save the hash in a table along with appropriate metadata. Then you save the binary content in /opt/datastore/$HASH . But… what happens if the hash doesn’t exist? How do you guarantee data consistence between the table and what’s on the FS? (hint: its really hard).

      Another issue is if you’re guiding someone else to do backup/restore/migration techniques. If everything’s in the DB, then it’s a backup and restore on another destination. Then copy over the configs, and you’re pretty much done. It’s effectively a “1 stop shop”. However splitting up the data in different dir’s means you also add complexity to backing up and restoring. And missing something is pretty easy.

      I’ve more been a fan of using 2 DBs: a regular DB and a documentDB. But there’s no one-size-fits-all.

      1. 1

        Pretty sure this was covered in the section talking about how we’ve lost transactions once the database is no longer the sole data system.