On Tue, Mar 27, 2012 at 1:24 PM, Leyne, Sean <[email protected]>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]
