There is an argunent for Putting NoSQL In Its Place.
The example given for selecting NoSQL over a RDBMS is:
A document = A page. As simple as that. Instead of crawling through nested loops and bringing data together from a multitude of locations, logically storing a chunk of application data in its native format is appealing. Is it always the right way to do things? Of course not. But it’s extremely intuitive, easy to develop against, and can be configured for concurrency, portability, redundancy, and nearly anything else you might want depending on the NoSQL engine you’ve selected.
I think the author has confused presentation with the data model. What is seen on the screen is not the data model.
A data model is how the organisation sees the world. The data model includes rules about how the world behaves, and what is worth knowing about the world. The data model is about how facts are constructed in the world-view of the organisation.
And the relational data model is agile because it allows facts to combined in different and interesting ways. How do I do that with documents without teasing them apart and examining them?
The author’s conclusion is:
NoSQL is not THE answer, but it is absolutely AN answer. In fact, I am a strong advocate of using it together with applications that use or should use a relational model. For transactional use requiring ACID compliance (most notably atomic, sequential operations) data can be stored in the relational database. Metadata, session data, logging, metrics, and other non-transactional information that is not required for the actual end user experience can be easily stored in one of many forms offered by the various NoSQL engines.
I am aghast at this. The data in the database has to be accurate. You cannot be so caviliar to suggest any data in the database is not transactional. Either a logical unit of work was completed, or it was not. Otherwise, you are going to have bits of information hanging around until you run a data integrity check.
Non-transactional databases are not new. I worked on one back in the 1980’s called CA-1. This was the tape management catalogue used in IBM mainframes. It was a pionter based database. And without transactions, we have dangling pointers, and tapes that were allocated but not referenced.
So, if there was a failure (software or hardware), I would have to try to detect the corrupted pointer chains and manually update them after reviewing reams of reports.
DBAs of today are so spoilt with automatic transaction recovery.
Believe me, I am a firm believer in ACID because I know what life is like without it.