When I got into programming I figured it would be mostly linear technological progression. Every once in a while something new gets invented that’s better than the last iteration, so we discard the last option (except for legacy stuff) and everyone moves to the better thing.
But since then everything that was cool back then became uncool and cool again at least once.
I like the SQL/No-SQL cycle. SQL is powerful, but it’s also slow and clunky and if you do it badly it gets really slow. So we invented No-SQL DBs. They are fast, lightweight, but also barebones and limited. So we add functionality here and there, and before we know it we have another variant of SQL with a different syntax. So we head back to use real SQL. But then we realize it’s slow and clunky and if you do it badly it gets really slow. So we invent a new No-SQL DB and the cycle continues.
It’s more that nosql makes sense of you have very specific performance characteristics and can accept very specific constraints.
Alternatively, you want to use a document db because you don’t understand that delaying implementing schema integrity or implementing it yourself in the application layer instead of having it baked into your database will be more complex and slow you down in the long run. RDBMS isn’t slower than a generic document DB.
That’s pretty much my point. Actual Nosql does have use cases, but more often than not it was used for hype reasons. “Everyone uses Nosql, let’s not become legacy and hop on the Nosql train!”
Document DBs came out of Nosql, and are pretty much the same as SQL for most use cases, just with their own funky syntax.
And then again there are the use cases where people use SQL without relations, basically as a Nosql DB. Just do ORM for everything, do the database stuff in memory in Java and just use SQL to dump crap into.
This here.
When I got into programming I figured it would be mostly linear technological progression. Every once in a while something new gets invented that’s better than the last iteration, so we discard the last option (except for legacy stuff) and everyone moves to the better thing.
But since then everything that was cool back then became uncool and cool again at least once.
I like the SQL/No-SQL cycle. SQL is powerful, but it’s also slow and clunky and if you do it badly it gets really slow. So we invented No-SQL DBs. They are fast, lightweight, but also barebones and limited. So we add functionality here and there, and before we know it we have another variant of SQL with a different syntax. So we head back to use real SQL. But then we realize it’s slow and clunky and if you do it badly it gets really slow. So we invent a new No-SQL DB and the cycle continues.
It’s more that nosql makes sense of you have very specific performance characteristics and can accept very specific constraints.
Alternatively, you want to use a document db because you don’t understand that delaying implementing schema integrity or implementing it yourself in the application layer instead of having it baked into your database will be more complex and slow you down in the long run. RDBMS isn’t slower than a generic document DB.
That’s pretty much my point. Actual Nosql does have use cases, but more often than not it was used for hype reasons. “Everyone uses Nosql, let’s not become legacy and hop on the Nosql train!”
Document DBs came out of Nosql, and are pretty much the same as SQL for most use cases, just with their own funky syntax.
And then again there are the use cases where people use SQL without relations, basically as a Nosql DB. Just do ORM for everything, do the database stuff in memory in Java and just use SQL to dump crap into.