Sean,

> I would suggest multiple server/database connections from within a
> single sql statement.
>
> For example, you may have accounting data on one server, while
> customer data is on another while inventory is on a third.
>
> You want to update customer, accounting and inventory levels all
> within a single transaction.
>
> (Very simple problem, complex numbers of solutions)
>
> You would encounter the same problems of live replication systems
> combined with the difficulties of programming language designers.
>
> There are over a hundred different problems that I can think of off
> the top of my head. The design criteria would be a paper onto
> itself.
>
> The final solution would use both distributed computing and cluster
> management. It would finally create a true purpose for the
> difference between "create database" and "create schema".
>
> Just a suggestion, but, it would be appreciated by a large portion
> of the FB community and it is sexy enough to get a few others to
> help when needed.

If you are interested in this topic, please check the C-JDBC project.
They target the "transparent replication" solution, and some parts of
the problem specified by Dalton might be already solved. There were
also talks about a "physical" replication solution in a manner similar
to the nbackup utility (basically the database pages).

And, naturally, I think the "firebirders" would appreciate an
open-source free and production ready replication solution :)

Also, if you go in that direction, you should check papers from the
Swiss Federal Institute of Technology (EPFL) (F. Pedone, B. Kemme et
al), they implemented replication for PostgreSQL, but the papers are
very educative.

Roman