[geophile]

Modern web apps are applications. Applications, over time, run into many problems that SQL database systems were designed to address:

* The occasional join.

* Complex queries.

* Reporting.

* Schema changes.

* Transactions, with options for trading off strictness and performance.

* Performance problems that are easily addressed using stored procedures.

* Performance tuning with minimal code changes (e.g. adding an index to change the execution plan of a complex query).

* Enforcement of invariants regardless of application code.

Why would you give these up for scalability problems you won't have, with 99.999999% probability?

[gizzlon]

"Why would you give these up for scalability problems you won't have, with 99.999999% probability?"

I'm not saying people shouldn't use RDBMS', but there are many reasons for using something else:

  - The new databases/stores have different features and use cases. Many include features RDBMS' do not have.
  - Having to use table/column's for everything can be quite unnatural and tiresome.
  - RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds.
  - At least for me, using & learning something new is a big motivation booster :)

Use whatever is right for the job. But one should at least have a general knowledge of whats out there: features, pros & cons etc..

[geophile]

"The new databases/stores have different features and use cases. Many include features RDBMS' do not have."

True. My view is that the tradeoff comes out overwhelmingly on the RDBMS side most of the time.

"Having to use table/column's for everything can be quite unnatural and tiresome."

Unnatural in the sense that it is different from the first language you learn, yes. What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation.

"RDBMS' are battle-tested and their pros & cons are well known. But they might also be based on legacy models and truths that simply no longer holds."

I really think you need to learn something about RDBMS fundamentals. Set theory certainly "holds" to this day, and is certainly not legacy. The relational model is clumsy for some kinds of data ( (e.g. time series), but saying that the foundation is obsolete is just objectively false.

"At least for me, using & learning something new is a big motivation booster"

No argument there. But now take the next step and do an objective comparison between old and new. I have no problem with NoSQL systems. I even built one. But for nearly all applications, when you account for a wide set of requirements, (not just what is needed to get the MVP up and running), I think an RDBMS is the right tool.

[gizzlon]

"What I find tiresome is low-level, record-at-a-time programming when doing what could be expressed concisely as, say, a 5-way join with aggregation"

Again, that depends on what you are doing. Converting back and forth between rows/tables and, say, data stored in hashes, is tiresome. It's also unnatural when the data doesn't "fit" in the relational model. Of course it works, but writing all this banal sql is not fun.

"I really think you need to learn something about RDBMS fundamentals...."

Right.. I was talking about the software. Maybe "models" is the wrong word.

"But now take the next step and do an objective comparison between old and new"

Believe it's pretty objective already.

[gaius]

The funny thing is hierarchical databases were all the rage in the 1960s (IBM's IMS for example) and the world moved on to the RDBMS.

I chuckle to myself when kids who wouldn't know a "legacy" app if it jumped up and bit them on the nose, go through the same thought process over and over again.