> Document stores, key-value stores, column-oriented databases, graph databases can all be more suitable for a given tasks than relational databases.
Can related features be add-ons to RDBMS rather than leaving the RDBMS world for good? Any non-trivial system will need at least some of what RDBMS offer. We should try not to throw out the baby with the bathwater.
I'd like to explore specific use-cases for NoSql to see what features they need that RDBMS currently lack and if it's impossible to practically add those features to RDBMS.
Dynamism of "structure" is about the only thing I can think of right now, and there are possible remedies, per "Dynamic Relational" mentioned nearby.
At some point when designing a data store, decisions must be made with regards to memory layouts, integrity, transaction guarantees, ease of replication, etc. These choices typically involve reliability vs performance tradeoffs for various use cases.
I mean, you _can_ store graph data in a relational database, but its' not typically easy to insert or query, there are serious performance penalties, etc. Purpose-built data structures will always out-perform generic ones.
Can related features be add-ons to RDBMS rather than leaving the RDBMS world for good? Any non-trivial system will need at least some of what RDBMS offer. We should try not to throw out the baby with the bathwater.
I'd like to explore specific use-cases for NoSql to see what features they need that RDBMS currently lack and if it's impossible to practically add those features to RDBMS.
Dynamism of "structure" is about the only thing I can think of right now, and there are possible remedies, per "Dynamic Relational" mentioned nearby.