One of the components of the UUID is drawn form the mac address of the server.. While in practice this is not true of all systems
(except from http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_uuid) Currently, the MAC address of an interface is taken into account only on FreeBSD and Linux. On other operating systems, MySQL uses a randomly generated 48-bit number. (end except) that potentially 48-bit random portion has 281474976710656 possibilities, which makes in far, far more likely that your server is hit by a meteor during a snowstorm in August while the Dalai Lama is doing an Elvis impression for the Chinese premier. - michael dykman On Fri, Jan 21, 2011 at 1:22 AM, Johan De Meersman <vegiv...@tuxera.be> wrote: > I have to say, something similar was my first thought, too - you never > mention uuid in your original post. As already stated, uuid() should be a > Universal Unique IDentifier. It's afaik a random 128-bit number; given the > space to choose from it should be rather unique. I have to admit that I'm > not entirely confident about that myself, either, though: as Pratchett put > it, one-in-a-million chances tend to pop up nine times out of ten. > > The code should have bits for handling duplicate primaries regardless of the > method used to generate it, tough, so there's no reason to not do it. Having > two subsequent UUID() calls generate pre-existing numbers seems to me to be > likely in the same way as having Bush return his dirty oil dollars to Irak. > > On Thu, Jan 20, 2011 at 8:10 PM, Anthony Pace <anthony.p...@utoronto.ca>wrote: > >> Dude, come on. I know that all primary keys have to be unique; however, I >> was obviously referring to the use of uuid over auto incrementation. >> >> On 1/20/2011 1:36 PM, Michael Dykman wrote: >> >>> It is axiomatic in the relational model that a primary must be unique. >>> This is not a quirk put forth by your current employer. Neither >>> MySQL nor any other RDBMS will allow you to establish a primary key >>> that is not unique. >>> >>> - michael dykman >>> >>> On Thu, Jan 20, 2011 at 1:32 PM, Anthony Pace<anthony.p...@utoronto.ca> >>> wrote: >>> >>>> Due to certain reasons, the company I am doing business with has decided >>>> that the primary key, for an orders table, be a unique key; however, I >>>> don't >>>> like the possibility of it conflicting if moved to another machine. >>>> >>>> What are some pitfalls of using a unique key, that is generated by a >>>> server >>>> side script, rather than by mysql? >>>> What are the best ways to do this? >>>> >>>> Please keep in mind this variable will also be displayed on the >>>> customer's >>>> Receipt, but again, since it's random, it doesn't have to mean anything. >>>> >>>> -- >>>> MySQL General Mailing List >>>> For list archives: http://lists.mysql.com/mysql >>>> To unsubscribe: http://lists.mysql.com/mysql?unsub=mdyk...@gmail.com >>>> >>>> >>>> >>> >>> >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe: http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be >> >> > > > -- > Bier met grenadyn > Is als mosterd by den wyn > Sy die't drinkt, is eene kwezel > Hy die't drinkt, is ras een ezel > -- - michael dykman - mdyk...@gmail.com May the Source be with you. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
