• Fine-grained Access Control for Stored Procedures
• Power BI Treemap Chart Step-by-Step Tutorial
• From the SQL Server Central Blogs - Extracting Data from the Planview Portfolios REST API using ADF – Introduction
• From the SQL Server Central Blogs - Writing Parquet Files – #SQLNewBlogger
• Pro T-SQL 2022: Toward Speed, Scalability, and Standardization for SQL Server Developers

• Sensitivity Ranks

NOSQL and RDBMSs

This editorial was originally published on Aug 27, 2015. It is being republished as Steve is traveling.

I first came across the term NOSQL in 2010 at a SQL Bits presentation by Simon Munroe.  Provocatively titled “Improving Database Performance by Removing the Database” it was both deeply disturbing but also strangely liberating.

The irony is that for all the NOSQL fanboyism from the extreme end of the development community many DBAs had also been quietly harbouring heretical thoughts about the way in which their databases were used.  The examples Simon used to articulate the case for NOSQL gave voice to those guilty thoughts.

Why do we use an RDBMS for….

• Web session state?
• Logging and auditing?
• Queueing applications?

I believe the development community saw themselves as experiencing a sort of data Glasnost and escape from the tyranny of the DBAs.  The death of relational technology was gleefully announced…..again.

Where there is change society divides itself into four camps which my experience tells me aligns to a bell curve (not drawn to scale).

The stick-in-the-muds took one look at NOSQL solutions and concluded (correctly at that time) that the technology was somewhat flaky and dismissed it out of hand.

The fanboys definitely saw the potential but forgot that RDBMS’s have survived and thrived for a reason.

At the heart of our RDBMS technology is a well thought out and robust model.  Thirty years of evolution and compromise have resulted in a balance of all the concerns that an RDBMS has had to cope with.  The technology has shown a robustness sufficing a number of concerns beyond those it was originally designed to satisfy.  These concerns have been driven by the commercial needs of customers for the technology.  

NOSQL recognises that commercial needs have arisen that require a different compromise, perhaps sacrificing certain attributes in order to favour others.

I think that both the stick-in-the-mudes and fanboys have failed.  The stick-in-the-muds failed in two ways:

• To consider that in order to satisfy new business models a different balance in the technology compromises must be made
• To consider the speed at which the NOSQL solutions were evolving.

On the flip side the Fanboys also failed:

• To consider that the RDBMS vendors would react and evolve themselves to rise to the NOSQL challenge.
• To consider that some of the ideas from the RDBMS world are actually pretty good and are why the technology has thrived for so long.

It is here that I would offer a few words of caution. The NOSQL vendors have re-discovered that some form of Structured Query Language is a useful abstraction for interacting with database technologies.  While I understand the pressure to adopt a SQL like language I do think it is a mistake to base that language too closely on SQL. I feel that basing their query language on SQL, while aiding adoption it will lead to lazy thinking by architects and developers.  It will prevent the exploration of key strengths of the NOSQL platform that do not fit easily with a language based on SQL.

In the RDBMS camp I can understand the attraction of being able to accept and process JSON and absorb other NOSQL type functionality but isn’t this precisely the one-size-fits-all approach to solutions that NOSQL solutions originally identified as a mistake?

David.Poole

Join the debate, and respond to today's editorial on the forums