The traditional RDBMS have failed because are all-or-nothing.
A lot of people here (and elsewhere) think is non-sense to build a full app with the full business logic inside the "db".
WHY?????
That is a VERY NARROW viewpoint.
But when we say "let's build a full-app inside a Virtual Machine, yeah that actually is ok!"
And why is ok to build a full app on lisp?
Or in a OO language (a grah of objects)?
Or a array language (a array is relation with 1 column!)
If you think that:
print([1, 2, 3])
Id OK. then YOU MUST ACCEPT THAT:
print([Code = 1, 2, 3; Name= Miami, New York, Bogota])
Is ALSO OK.
The relational model is just move from 1-columns arrays to 2 N-Columns (In rows of columns as internal storage) plus some universal operations.
WHERE THE RDBMS FAILED EVERYONE IS:
Because them (the guys at the DB side) insist in adding: transactions, triggers, Surrogate-Keys, Inter-Relation dependencies, storage, sub-query languages, catalogs, views, etc.
So at the end, you get a full half/big semi-OS virtual machine tailored to a specific niche.
------
Was only when the artificial divide between the RDBMS and the front-end language appear (and the death by MS of Fox/Vb to only focus in .NET) that building database apps start to suck big time.
I have talk about in HN before about this, and instead consider that make even MORE sense to build the logic inside the DB, however, is necessary to re-think how it look to make it more useful. Is not a novel concept. The dBase family was almost that, and the people like me that use it was very happy and productive.
Why make more sense? Because Program = Data + Algo.
Data is not to be treated as third-class citizen. Must be a first class. The relational model make it first class (as with lisp model and array).
And what about separation of concerns and all that? That is pure architecture and is tangential to be or not inside a DB, the same is tangential inside a VM.
A lot of people here (and elsewhere) think is non-sense to build a full app with the full business logic inside the "db".
WHY?????
That is a VERY NARROW viewpoint.
But when we say "let's build a full-app inside a Virtual Machine, yeah that actually is ok!"
And why is ok to build a full app on lisp? Or in a OO language (a grah of objects)? Or a array language (a array is relation with 1 column!)
If you think that:
print([1, 2, 3])
Id OK. then YOU MUST ACCEPT THAT:
print([Code = 1, 2, 3; Name= Miami, New York, Bogota])
Is ALSO OK.
The relational model is just move from 1-columns arrays to 2 N-Columns (In rows of columns as internal storage) plus some universal operations.
WHERE THE RDBMS FAILED EVERYONE IS:
Because them (the guys at the DB side) insist in adding: transactions, triggers, Surrogate-Keys, Inter-Relation dependencies, storage, sub-query languages, catalogs, views, etc.
So at the end, you get a full half/big semi-OS virtual machine tailored to a specific niche.
------
Was only when the artificial divide between the RDBMS and the front-end language appear (and the death by MS of Fox/Vb to only focus in .NET) that building database apps start to suck big time.
I have talk about in HN before about this, and instead consider that make even MORE sense to build the logic inside the DB, however, is necessary to re-think how it look to make it more useful. Is not a novel concept. The dBase family was almost that, and the people like me that use it was very happy and productive.
Why make more sense? Because Program = Data + Algo.
Data is not to be treated as third-class citizen. Must be a first class. The relational model make it first class (as with lisp model and array).
And what about separation of concerns and all that? That is pure architecture and is tangential to be or not inside a DB, the same is tangential inside a VM.