On Tue, Mar 27, 2012 at 1:24 PM, Leyne, Sean <Sean@...>wrote:

> Nathanel,
>
>
> - "Ann thanks for your comments, but you are also an idiot, perhaps you
> should get _your husband_ to show you how it can be done"
>

Sean, thanks for the defense, but hey, I'm used to that.

Yes, for some types of sharded applications all that's needed is the
ability to produce unions and the relative performance of those doesn't
matter. But suppose you have a database with more than one table and
somebody asks you a question that can be answered only by joining the
tables. Or even a database with one table and wake up one day wanting to
do a reflexive join. At that point, unless you've been awfully clever and
managed to put the related parts of every table on the same shard, you do
need cross-shard joins. That's not the worst part. Sooner or later, you
may need to store related data on more than one shard. Then you need a
two-phase commit to guarantee that both shards behave the same way.
Firebird does have a two phase commit, but it's much less efficient than a
normal commit.

There have been many times during the history of InterBase and Firebird
when the question of cross-database SQL operations has been raised - first
time was about 1985, I think. Most of them foundered in the sea of
optimization. This is certainly not the only time I've heard "but I don't
need the full functionality". A little more probing always turned up a
case where optimization matters. And yes, my husband is working in that
area, though his solution focuses on making thousands of small queries
faster rather than making a single select of a huge amount of data faster.
But that's another story.

Good luck,

Ann


[Non-text portions of this message have been removed]