On Friday, January 21, 2011 09:23:47 am Jerry Schwartz wrote:
>
> [JS] A UUID (what Microsoft calls a GUID) is based in part on the MAC
> address of the generating device. Since MAC addresses are supposed to be
> unique across the known universe, so should a UUID.
>
Not entirely true - and even
>-Original Message-
>From: Michael Dykman [mailto:mdyk...@gmail.com]
>Sent: Friday, January 21, 2011 11:35 AM
>To: Johan De Meersman
>Cc: Anthony Pace; mysql.
>Subject: Re: best way to have a unique key
>
>One of the components of the UUID is drawn form the ma
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
a
>-Original Message-
>From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De
>Meersman
>Sent: Friday, January 21, 2011 1:22 AM
>To: Anthony Pace
>Cc: Michael Dykman; mysql.
>Subject: Re: best way to have a unique key
>
>I have to say, som
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 e
http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
> -Original Message-
> From: Krishna Chandra Prajapati [mailto:prajapat...@gmail.com]
> Sent: Thursday, January 20, 2011 10:45 AM
> To: Anthony Pace
> Cc: mysql.
> Subject: Re: best way to have a un
I should have read more carefully.. I apologize for my snap response.
At a guess: as I recall, under M$ SQLServer the typical (only?) form
of unique identifier used is something very UUID-like. MY information
might be dated. I was certified as a SQL Server administrator perhaps
12 years agoI wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What conflicts are you expecting? according to the documentation:
A UUID is designed as a number that is globally unique in space and
time. Two calls to UUID() are expected to generate two different
values, even if these calls are performed on two sep
Although I did berate you for your obvious cheek, I will of course
complement the acuteness of your response.
On 1/20/2011 2:10 PM, Anthony Pace 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
I know of uuid() my problem is that there can be conflicts when copying
the DB to a different machine, or working with sections of the db on
different machines for load balancing.
On 1/20/2011 1:44 PM, Krishna Chandra Prajapati wrote:
> Please keep in mind this variable will also be displayed
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 y
uuid()
Krishna
On Fri, Jan 21, 2011 at 12:02 AM, Anthony Pace 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.
>
>
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
13 matches
Mail list logo
