Bob Martin: NO DB. Me: Any Sane DB.

The venerable OOP guru Bob Martin has weighed in on SQL, and NoSQL. He admits candidly to disliking SQL databases, and the way they just jumped in and dislodged non-database centric developer's lives. Their ubiquity, at one point, and the belief that any kind of persistence layer other than an SQL database persistence layer was somehow "not good enough" lasted nearly 25 years in our industry. I started out, and remained until recently, an SQL-database hater, conditioned to hate SQL by the bitter experience of many projects where it seems that SQL and the concerns around it, destroyed the project, and the company. I especially learned to loathe IBM DB2, on OS/2, and a series of misbegotten attempts at multi-tier database application architectures. I learned quite recently that SQL is actually not too bad. I don't love it. But I don't hate it either. I have however, learned that proprietary data-stores that are home-brewed can have quite a lot of glitches, and are generally not to be trusted. If there's two things I hate more than SQL databases they are:

Private binary-repository stores used as the primary repository for critical customer data.

Any persistence system that is not trustworthy.

A trustworthy system must have at least three of these four characteristics:

Be fully unit tested. (SQLite=Yes)

Be widely used by respected/large products (SQLite=Yes)

Not have lots of people ranting about why it sucks (MongoDB,CouchDB, etc).

Open source to prevent vendor lockin.

I have one non-negotiable, too:

Not have misfeatures, that cause data loss, that make me hate it. (Remember subversion's early BSDDB back end? I still haven't forgiven BSDDB or Subversion for that.)

Having said that, my current job, and my previous job have involved working with Microsoft SQL Server, and as commercial databases go, it's actually pretty nice. And if your database is small, it's free, with the "Express" edition. Nevertheless, it's hardly painless. It seems very easy to make mistakes that you will only realize are mistakes after years of work. That's why the "DBA" and the "Database developer" roles were born; Because doing SQL databases is hard work, and screwing them up is easy.

Lately, I have become very interested PostgreSQL, which is a hybrid database, offering classic SQL features, and a lot of great stuff that the NoSQL crowd has come to offer as well. I also have a lot of respect for SQLite, and for desktop-only zero-configuration cases, I have come to prefer it. However that stance is new for me. I actually had a very loud argument, where I was completely (irrationally, and wrongly) against ever using SQLite in any Delphi application written by any team involving me. Hey Steve, if you're reading me; I was wrong. SQLite is actually kind of awesome.

I realize that the DB world and the persistence-layer of programming, are hotbeds of opinions. ORMs are great. ORMs suck. Automatic OOP persistence layers are a current area where debate is raging loudly. The classic "SQL for everything" people tend to value hand-crafted SQL and queries, and so any layer that tries to map (via an ORM) objects to SQL is going to suck, in some cases. However, if you want a non-relational persistence model (which is actually ideal for many classes of problems), you're always going to be wondering if you went the wrong way, when you get yourself into the sorts of troubles that SQL-based solutions don't suffer from. How about the debate between the "Scalability Über-Alles" crew and the "Data Integrity Über-Alles" crew. It's a holy war, and it's on.

There are no silver-bullets. But there are some lead-balloons out there.