Relational Database Design Vs. Non-Relational Database

Posted In DigitalOlympus News - By Josh Cole On Thursday, July 18th, 2013 With 0 Comments

According to industry expert Jeff Cogswell, relational databases have ruled the data world since the early 1970s. But since the arrival of non-relational databases around 2009, apparently all hell broke loose on the Web. There have been (and will be) more than a few heated arguments about the following question: Which one is better?

It’s difficult to say how relational databases differ from non-relational databases because both represent a broad range of possibilities. However, I started to notice similar arguments that appeared over and over again in different specialized articles. And while these arguments may not be entirely accurate, at least will help us identify some common pros and cons.

Pros and Cons: The Battle of the Databases

Relational Database: You could say relational database design is the “Citizen Kane” of database management. It’s a classic, but it remains as relevant as ever. As explained by Tony Bain, a relational database is basically a group of tables made up of columns and rows. And once relationships have been defined between them, they are queried using SQL (Structured Query Language).

Some of the most important SQL database examples include commercial products like IBM DB2, Oracle RDMS, Microsoft SQL Server, Sybase SQL Anywhere; as well as some Open Source examples like MySQL, and Ingres.



  • It has dominated the market for over 30 years.

  • There are extensive code libraries to help you develop client code.

  • It’s a very powerful system.

  • It can map most data.

  • It ensures that its database performance is always consistent.

  • It makes it easy to move data from one database to another.

  • Some say it’s becoming outdated.

  • It doesn’t map well.

  • It has a difficult time with complex or hierarchical data, especially XML.

  • Its joins can slow down the system.

  • It can be difficult to write client code.

  • When scaling requires more than one single server node, it becomes problematic.

Non-Relational Database: Usually called a “key/value store”, this database management system is item-oriented instead of being made up of tables with columns and rows. This means that all valuable data associated to a specific item is stored within that very item in order to improve scalability.

Many experts agree that this database system was inspired by Google’s BigTable and Amazon’s S3. Currently some non-relational database products include: Cassandra, MongoDB, HBase, CouchDB and many more.



  • It’s new and shiny, and also best suited for cutting-edge web and cloud applications.

  • It helps busy sites achieve extremely low latency.

  • It simplifies development, and provides an easier programming model.

  • Provides massive scalability.

  • It allows to increase the capacity of your database on demand.

  • Most non-relational databases are still in Beta.

  • Maintaining data integrity depends completely on the application.

  • It’s prone to errors and bugs.

  • It’s less compatible than traditional relational database.

  • It has limitations when it comes to analyses involving queries.

  • It prioritizes speed over accuracy when doing queries.

And The Winner Is…

Truth be told, Non-relational databases are pretty easy to use. But, SQL programming has been around for so long that it almost feels natural. So who wins? Well, you decide. My opinion is that if you’re working with complex data that fits nicely into a tabular structure, you should go with relational. However, if you need to use quick access to individual objects, then try non-relational databases.

So use both. Mix it up a bit. If you have something to bring to the table regarding database solutions, please feel free to leave your comments below, and we’ll discuss it with our online community.

About -

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>