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

but NO NO NO it's was never never an attach... ouch big misunderstanding here ... oulalala i will now read more carefully my message before to send it !

> 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.

yes, and this where end the idea i have in mind ... better than nothing no ? at professor was accomodate to say me that i will do 20% of the work for 80% of the functionality but the last 20% of the functionality will cost me 80% of the work ...

> 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.

yes but this is too far away for what i was thinking at the begining. the few database application that i try and that offer sharding don't go so far. sphinx for exemple, used by craiglist and that support 200 000 000 millions queries a day use the simple sharding on 15 server (and in sphinx if you even forget to put in the select the fieldname that are in the orderby it's crash at the end in the union of the data saying he can not sort because doesn't have the field).