[tsahyt]

There's a lot going on and that's the way it has been for quite a while now but as someone who's working with databases only marginally at the moment, I'm left wondering: What's wrong with RDBMS? Sure it's nice to have a simple Key-Value Store for applications that don't need much more than this but bottom line, the relational model is very powerful, albeit quite abstract, and most data we need to deal with can be made to fit into this model. We have a working, declarative query language that Just Works(TM), for which we have written very good optimizers. The various instances of such DMBS range from small-scale use (for example, SQLite) to really-huge (Postgres, Oracle, etc). So, to sum it up: Exactly why should we abandon this?

[lmm]

> the relational model is very powerful, albeit quite abstract, and most data we need to deal with can be made to fit into this model

Maybe, but it's awkward. Graph or tree structures are still painful to store in relational databases, and a lot of problems turn out to involve those shapes.

> We have a working, declarative query language that Just Works(TM), for which we have written very good optimizers.

Maybe, but the tooling is still terrible. Where are the libraries? Where are the IDEs? Where's the integration that makes it easy to call procedures in my application language from SQL and vice versa? General-purpose programming languages have got better and better in the last 25 years, while SQL has stayed static.

> So, to sum it up: Exactly why should we abandon this?

Look at the ORM problem. Why do people continue to use these horrific bloated, leaky tools? Because it's really nice to be able to store and query in the native language of your application. We need storage tech that's better at supporting this.

[VLM]

Most boots on the ground DBAs don't know anything about rational DB design. Codd Normal form? Whats that? Can't I just make one giant table? Indexes? Why would I want indexes? I heard they take up disk space and CPU so I won't use any, to increase performance. So they (poorly) implement key value stores regardless what the problem actually requires (if the only tool you know how to use is a nail...). Nothing funnier that watching a noob do a select * on a large table transferring gigs of data and use his RoR app to implement the WHERE using nested ruby if statements and string comparisons (or better regexes without understanding regexes, LOL) and god help me a bubble sort instead of an ORDER BY clause and of course hit another table once for each row selected from the first table because he doesn't know JOINs even exist, or heard they're "slow".

A RDBMS is a very slow key value store, so anything that can't do transactions or can't do anything else, is always going to be faster at its extremely limited set of abilities.

From an engineering perspective if you need 10 HP to run your 5 KW generator, a RDBMS is like installing a 10000 HP marine diesel and then not having any idea how to start or maintain it or even where to get the fuel. Obviously every objective performance metric would be better for a 10 HP lawnmower engine in that app, if all you'll ever plan to use is 10 HP and you have no idea how to use anything more advanced anyway.

There are also very loudly trumpeted anecdotal situations or contrived thought experiments where certain unusual technologies fit a unusual situation very well. This is, oddly enough, unusual.

I've read and experimented with the "7 DBs in 7 weeks" book and it IS very interesting but I can't find any business cases to actually use any of it, which is somewhat frustrating. And my experience is how you end up with people writing CRUD apps to store cooking recipes that none the less use NEO4J because they really, really, want to add a line to their resume that they used NEO4J, not because the app needed it.

[StefanKarpinski]

Condescend much?

[VLM]

When I'm right, yeah. Not using "engineer" as a title of authority but as a problem solving technique, maybe the TLDR is its an engineering problem where non-engineers mess up RDBMS incredibly often, and when its blame time, better off blaming the tool than the "designer" so...

"I don't know what I'm doing, but someone who knows what they're doing anecdotally solved a completely different problem using tool XYZ, so for lack of any better idea, lets copy them".

If you're familiar with cargo cult science there is an enormous miasma of cargo cult engineering fogging up the entire database arena not just nosql.

Another concept that needs to be in the discussion is the "no silver bullet" rule from programming applies to database design, like it or not. Can't just sprinkle magic nosql pixie dust on any old random problem and expect it to work, any more than applying any random programing fad to any random problem will work.

The (old and new) tools are actually pretty interesting, although often poorly engineered (by the end user) and implemented. Its the persistent anti-patterns and non-engineering design technique that I'm properly arrogant and condescending toward.

Hammers are a cool new invention and have some great unusual new applications, but they don't install deck screws any better than the legacy screwdriver. Laborers on the job randomly mixing screws nails screwdrivers and hammers on the job and then internet discussions about how hammers and/or screwdrivers suck is nearly physically painful to watch.

[StefanKarpinski]

Regardless of whether you are right or not, your tone is very off-putting. This is not an academic concern – this sort of attitude is a huge part of why the tech community ends up being very exclusionary. Oh yes, watching someone make mistakes while learning how to build a web application or learn regular expressions is hilarious. Much better to laugh condescendingly while watching them struggle than try to help. Concocting "straw man" noobs everywhere who do things in obviously wrong ways doesn't make you more right. And it definitely doesn't make you smarter. It just makes you seem like a jerk and makes it a little harder for people to stomach getting into the tech field. Please stop.