> I understand and accept that this is current best practice and that
> good engineers build applications this way. But to me it is a work-
> around for failing rdbms technology, not unlike MySQL's arguments six
> years ago that a rdbms did not need transactions, ref integrity,
> stored procedures, etc., as all of that could be done in the
> application.
> ...
> There is a relation to partioning. Current technology is good at
> doing efficient single node joins, but poor at doing cross-node
> joins. Many scalability engineers advocate denormalising data to deal
> with it. This, too, sounds like a work-around.

Not sure. There was a long debate in OODBMS world whether encapsulation
is applicable for databases or not. The purists were talking that if we
want to have _OO_ DBMS, then data should be encapsulated. But the other
part was claiming that encapsulation hides the costs of data access
paths, therefore no optimal plan can be selected at all...

My gut feeling tells me that you can't really ignore the data location
in distributed RDBMS too. But if you start splitting your data on local
and remote ones, you will always want to cache one or another portion of
data on the same node to minimize the costs. But then you start asking
about data consistency. And so on.

There are other similar cases. For example, airline ticket reservation
systems. If you consider different travel agencies and different
airlines, this is a classical example of a distributed database. To keep
data consistent, you would go for two-phase commit for ticket
reservation transactions spanning, let's say Lufthansa, KLM and Delta.
Can you do this? I doubt :) But even if you could, you wouldn't do this
- too much overhead. And the real-world applications don't do this
either - they simply allow overbooking. They call this "relaxed
constraints".

Roman