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 <vegivamp@stripped> 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.pace@stripped>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.pace@stripped>
>>> 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=1
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>>
>>
>
>
> --
> 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
- mdykman@stripped
May the Source be with you.
