"Actually, it is the Relations Data Model which might well prove to have been a failed experiment or at the very most a brief distraction."
What a joke. The failed experiment, or brief distraction, of the Relational Model and SQL has gone on twice as long as this guy's programming career, and is still going strong.
Not to mention that the actual basis for the Relational Model is the mathematics of set theory.
Like an essential mathematical theory can be a "failed experiment" to be substituted by some random ad-hoc model.
Anyone saying "theory doesn't work out in practice" is an idiot who shouldn't be allowed near a computer. Proven theory works each and every time with the set of constrains it defines in its operating environment. What he confuses as relational model's shortcomings are implementation details of RDBMS systems (storage of sparse data, etc).
And when he proposes NoSQL as the solution, he compares apples to oranges. The two solutions do not offer the same thing in respect to data integrity, assurances about the model, etc. You just get a more flexible model and (debatable) more speed.
Actually, is he aware that NoSQL was the norm BEFORE SQL, and that that was the original failed experiment? There were hundreds of proprietary, ad hoc, flat or hierarchical data storage/query solutions. People were doing that, and they stopped and adopted SQL.
Now, the reason NoSQL come to prominence of late is, easy to setup, easy to hack together some models, matches the dynamic language use well, fast to get some stuff going (that for solitary hackers --for large systems is equally or slightly less a pain to setup as SQL, and you have to implement most of the assurances yourself on top of it).
So, the main reason large teams/systems use NoSQL is: speed and easy ad-hoc schema changes.
Ad-hoc schema changes are nice, but do not fit all business domains. They are the GOTO of 201x, leading to a mess of spaghetti code and edge cases. I wouldn't touch those with a ten foot pole in a financial/banking/legal etc application for example. For a web system it could be OK, but would you want to want with a codebase with accumulated arbitrary schema changes after a decade for something like Amazon or Facebook? Even if the code is perfectly maintained and refactored once in a while, you get everybody's different approach to ACID (or lack thereof).
I like the approach of 37 Signals, which throws hardware (not even horizontally) at their scaling problems and insists on a regular SQL solution.
As for speed (of SQL/NoSQL), it can be a non-issue with total in memory databases and horizontal scaling (the future "dynamic memory cloud").
3 comments
[ 3.2 ms ] story [ 23.5 ms ] threadWhat a joke. The failed experiment, or brief distraction, of the Relational Model and SQL has gone on twice as long as this guy's programming career, and is still going strong.
Like an essential mathematical theory can be a "failed experiment" to be substituted by some random ad-hoc model.
Anyone saying "theory doesn't work out in practice" is an idiot who shouldn't be allowed near a computer. Proven theory works each and every time with the set of constrains it defines in its operating environment. What he confuses as relational model's shortcomings are implementation details of RDBMS systems (storage of sparse data, etc).
And when he proposes NoSQL as the solution, he compares apples to oranges. The two solutions do not offer the same thing in respect to data integrity, assurances about the model, etc. You just get a more flexible model and (debatable) more speed.
Actually, is he aware that NoSQL was the norm BEFORE SQL, and that that was the original failed experiment? There were hundreds of proprietary, ad hoc, flat or hierarchical data storage/query solutions. People were doing that, and they stopped and adopted SQL.
Now, the reason NoSQL come to prominence of late is, easy to setup, easy to hack together some models, matches the dynamic language use well, fast to get some stuff going (that for solitary hackers --for large systems is equally or slightly less a pain to setup as SQL, and you have to implement most of the assurances yourself on top of it).
So, the main reason large teams/systems use NoSQL is: speed and easy ad-hoc schema changes.
Ad-hoc schema changes are nice, but do not fit all business domains. They are the GOTO of 201x, leading to a mess of spaghetti code and edge cases. I wouldn't touch those with a ten foot pole in a financial/banking/legal etc application for example. For a web system it could be OK, but would you want to want with a codebase with accumulated arbitrary schema changes after a decade for something like Amazon or Facebook? Even if the code is perfectly maintained and refactored once in a while, you get everybody's different approach to ACID (or lack thereof).
I like the approach of 37 Signals, which throws hardware (not even horizontally) at their scaling problems and insists on a regular SQL solution.
As for speed (of SQL/NoSQL), it can be a non-issue with total in memory databases and horizontal scaling (the future "dynamic memory cloud").