Relational DBs are the new black

This article pits the custom relational databases against off the shelf, "configurable" systems.

by Hagen - March 2018

While this article could be about the misuse and overuse of NoSQL databases (rude language alert), it focuses on pitting the custom relational databases against off the shelf, "configurable" systems.

I will make the argument that the configurability of off the shelf systems often has mostly drawbacks, with none of the so called "benefits".

At the most basic level, web based systems are about reading data from and inserting data into a DB.

Would it therefore not stand to reason, that the simpler and cleaner the database, the "better" the web based system?

With "better" being defined as:

  1. More scalable i.e. handling more load with less hardware: A simple DB means simple queries
  2. Less bugs: if a system is essentially about data in and data out, then a simpler database should mean less bugs due to simpler queries and workflows
  3. Easier to maintain: Simpler means easier to understand and easier for new developers to get up to speed with
  4. Easier to extend: If the database is small and relational it is easily extended with new tables and updated relationships. With an off the shelf system, a new requirement might throw the entire thing out of kilter

The big misnomer is that clients want the ability to configure things themselves.

We have been in this game for more than 10 years and I've yet to see a client that actually uses the configurability of a CMS and updates settings and add sections themselves. They send an email or pick up the phone and make us do it.

The result, none of the benefits of the CMS are realized. Craft CMS

What is the tradeoff?

Take the following example and in this case, we will use Craft CMS as an example (which, as far as CMS' go, is our favourite).

Requirement: A website has an article section and the client wants to now add a short description to appear on the listing page. They wish to be able to configure this short description from the backend.

Scenario 1: Craft CMS
  1. Client emails Lima Bean to add a short description field
  2. Lima Bean logs on to and creates this new field and associates it to the article section
  3. Lima Bean add a line of code to the front end template to display the field
The database is updated as follows:

Other platforms solve this problem differently. For example Wordpress serializes everything (terrible to work with and horrible for performance) and Magento uses the EAV model (which has been called a bastardidation of the relational database model). Both these options are inferior to how Craft CMS does it.

Scenario 2: Custom DB
  • Client emails Lima Bean to add a short description field
  • Lima Bean log into a Database manager and adds the field to the article table, directly on the database
  • Lima Bean add a line of code to the back end template to display the field
  • Lima Bean add a line of code to the front end template to display the field
The database is updated as follows:

The verdict?

The time to perform the two actions is almost identical, the client's experience is identical, but, the end result in terms of the database structure is vastly different. The one is convoluted and complex, the other simple and clean.

While this is a simplistic example, I have found that this concept can often be extrapolated.

Unless a website is really just a simple brochure site (in which case Wordpress is FINE), then using off the shelf, configurable systems are often not the way to go.

The more complex and unique the underlying data relationships are, the stronger the case for custom designing a relational database is.

Long story short, CMS and other off the shelf systems are overrated. If you care about scaling, writing clean, efficient, lightweight, extensible systems, then for goodness sake base your build on a proper relational DB that models the entities and their relationships properly.