J J wrote:
... I simply believe in the right tool for the right job,
and you can't beat an RDB in it's domain. ...
That's something I've never really understood: what is the domain in which Relational Databases excel?
- Data too large to fit in memory? Well, most uses today may have been too large to fit in memory 20 years ago, but aren't today. And even for really big data sets today, networks are much faster than disk drives, so a distributed database (e.g., a DHT) will be faster. Sanity check: Do you think Google uses an RDB for storing indexes and a cache of the WWW?
- Transactional processing with rollback, three-phase commit, etc? Again, these don't appear to actually be used by the application servers that get connected to the databases today. And if they were, would this be a property of relational databases per se? Finally, in world with great distributed computing power, is centralized transaction processing really a superior model?
- Set processing? I'm not sure what you mean by set data, JJ. I've seen set theory taught in a procedural style, a functional style, and in an object oriented style, but outside of ERP system training classes, I've never seen it taught in a relational style. I'm not even sure what that means. (Tables with other than one key, ...) That's not a proof that relational is worse, but it does suggest to me that the premise is worth questioning.
- Working with other applications that are designed to use RDB's? Maybe, but that's a tautology, no?
I'm under the impression (could be wrong) that RDBMS were created to solve a particular problem that may or may not have been true at the time, but which is no longer the situation today. And what are called RDBMS no longer actually conform to the original problem/solution space anyway.
Regards, -Howard