On Mon, September 13, 2010 15:37, Daevid Vincent wrote: >> -----Original Message----- >> From: Kiss D�niel [mailto:n...@dinagon.com] >> Sent: Monday, September 13, 2010 5:59 AM >> >> Well, thanks, but I'm afraid using UUID's (even with hex >> compression) is >> kind of a suicide, when it comes to performance. >> This is a good summary about the issues: >> http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/ > > Is this UUID issue unique to mySQL or are there other RDBMS's that handle > it better (Postgress, Oracle, SQL Server, etc?) > > I too have a need for a unique identifier that will "mesh" with other > databases periodically. So that a user in one "local" DB/server will get > migrated to a master DB which in turn will sync up with remote sites so > that all sites will have all users in it each night (for example). >
> Having a mapping of UUID to local ID seems one way, but I feel there is a > lot of room for collisions and integrity issues that way no? > > There are some solutions at the bottom of that blog post. Are those not > good then? They seem interesting to me. Why does it have to be one field.� Two fields: ServerID and the SequenceID Across servers the pair would be unique and within a given server the Sequence ID is the equivalent of a "manual auto-increment fields"�� Set it via Max(SequenceID)+1 where ServerID is the local serverID.�� Have an index set for the combined fields as well as the Sequence ID field perhaps.� SOURCE IP FROM HEADER: ************************************************ *Please block this account's access to the * *internet until its cleaned up. We are basing * *this on an analysis of the header NOT the FROM* *address. * ************************************************ ------ William R. Mussatto Systems Engineer http://www.csz.com 909-920-9154
