Re: TODO item: GUID
От | mark@mark.mielke.cc |
---|---|
Тема | Re: TODO item: GUID |
Дата | |
Msg-id | 20060909220316.GA32672@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: TODO item: GUID ("Aleksandar Dezelin" <dezelin@gmail.com>) |
Ответы |
Re: TODO item: GUID
Re: TODO item: GUID |
Список | pgsql-hackers |
On Sat, Sep 09, 2006 at 07:47:19PM +0200, Aleksandar Dezelin wrote: > Hello, > you just have to make random 128 bits and set version bits. And that's all. > This is the way this data type is implemented in Mono > (http://svn.myrealbox.com/source/trunk/mcs/class/corlib/System/Guid.cs). > > Using time based GUIDs in database tables is not a good choice for > performance reasons because they can not be indexed properly - every newly > created time-based GUID is guaranteed to be larger than all previously > created, so RDBMS engine must re balance b-tree every time a new GUID item > is added to data table. > > Sorry, for sending this message three times - problem with Gmail. Depends how badly you want to skew the odds that a newly generated ID is actually new, and how much you trust the distribution of your random number generator. There are several ways to generate a UUID - and I think it is wrong to say that only one is the right way. Different applications choose different generation routines. I *like* sorting by time, as it allows the UUID to be used similar to sequence, leaving older, lesser accessed UUIDs in the past. You and Mono might prefer something else. Some choose random numbers over the MAC address as well - better? Depends on how big your system is. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bindthem... http://mark.mielke.cc/
В списке pgsql-hackers по дате отправления: