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