"[C. S. Lewis] showed me that newness is no virtue and oldness is no vice. Truth and beauty and goodness are not determined by when they exist. Nothing is inferior for being old, and nothing is valuable for being modern. This has freed me from the tyranny of novelty and opened for me the wisdom of the ages."
-- John Piper, How C. S. Lews Awakened John Piper to the "Realness" of Life, April 02, 2018.
**9**What exists now[ah] is what will be,[ai]
and what has been done is what will be done;
there is nothing truly new on earth.[aj]
10 Is there anything about which someone can say, “Look at this! It is new”?[ak]
It was already[al] done long ago,[am] before our time.[an]
11 No one remembers the former events,[ao]
nor will anyone remember[ap] the events that are yet to happen;[aq]
they will not be remembered by the future generations.[ar]
So, why am I quoting a renowned Christian author and the Old Testament here? Because, even in technology, in software development, there is nothing new under the sun. Let me explain...
In the last two years, I have been learning about MongoDB. Now, if you have any current knowledge of software development tools, you probably know something about MongoDB... unless you are a mainframe COBOL programmer with no intellectual curiosity whatsoever. ;) Of course, the most well-known fact about MongoDB is that it is a "NoSQL" database which is to say that it is decidedly not relational.
For many years before my introduction to MongoDB, I was a relational database junkie using on or the other RDBMS as the backing store for my applications. Over the years, I believe that I had become -- and still am -- a pretty darned decent relational database architect, designer and developer.
As I began to explore the world of MongoDB (my own personal "Oz"), many of the relational database tenets I have long held dear and perhaps even inviolate have caused twinges and cringes and gasps ("Oh, my!").
For example, joining a document (a row?) from one collection (a table?) with one or more documents in another collection is discouraged. Rather, one is encouraged to create sub-documents in one of the collections containing the document(s) from the other collection which thereby eliminates the need for a second collection.With joins greatly discouraged, it was no surprise to find that 3NF is not a thing, either.
"What is 3NF?", you say? You know... 3rd Normal Form... where "Every column is dependent on the key, the whole key and nothing but the key, so help me, Codd!" What? You never heard of that? Right. Anyway... 3NF is not a thing in the non-relational world. Well, actually, it is a thing but seemingly a bad or undesirable thing.
The more I learn about MongoDB, the more it starts to feel familiar... like... I've seen something similar to this before. This "knowing" continued to grow for a while and then, one day... click... whir... there it was! Indexed Files.
Do you remember Indexed Files? This was a "flat file" with indexes to directly access records in the file. There were variations of this theme on every operating system. IBM's mainframes had ISAM and VSAM files; DEC's VMS, RMS Indexed files; HP's MPE, KSAM files; MS-DOS, Btrieve (3rd party)... the list goes on and on. Generally, these indexed file systems required one unique index for the records while supporting one or more additional indexes that might or might not be unique. However, the format of individual records was not required to be consistent.
Document databases are very similar. Sure, there is general support for JSON input and output and the fields in each document are named, but the concept of a document schema is very, very loose. Validation is generally provided by external code or logic (in apps or ORM/ODM definitions). Their forté is lightning-fast access to data -- perhaps multi-level documents.
Relational databases -- which provide similarly flexible indexing options -- provide a much stronger definition of the data and relationships being stored. Used properly, this ensures that an application cannot store inconsistent data in the database.
In the end, it seems to me that a document database sits somewhere between the archaic indexed file systems -- which left everything except the indexing up to the application -- and relational databases -- which provide highly evolved facilities for data validation and integrity.
To my way of thinking, there is not that much new about document databases. They are a mashup of indexing facilities and "roll-your-own" content with the server-side processing provided by most relational databases.
Getting back to my original point...
Relational databases -- old and antiquated though they may be -- are not necessarily "bad". In fact, a decent RDBMS provides validation, constraints and integrity that are meager to non-existent document databases (i.e., MongoDB)... unless you use a third-party library (e.g., Mongoose or MikroORM).
For that matter, indexed file systems though older than relational databases, are not necessarily "worse". For applications written in certain environments in legacy languages, they may be the best choice.
Likewise, a document-oriented (NoSQL) DBMS, though the newest of all, are not necessarily "better" or "best" for every circumstance. Certainly, though, there are many use cases where NoSQL reigns, particularly in Web-based apps.
Lastly, I am not here to argue that a good RDBMS (e.g., PostgreSQL, SQL Server, Oracle, etc.) is the "right" data store for every purpose. However, there are many line-of-business applications where a relational -- or object-relational -- data store provides data integrity features that are beyond compare.
When it comes to data storage, old and new technologies alike have strengths and weaknesses. Choose your platform(s) carefully.