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.
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.