Message-ID: <48A18E64.10707@mark.mielke.cc>
Date: Tue, 12 Aug 2008 09:21:40 -0400
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Bill Moran <wmoran@collaborativefusion.com>
CC: Gregory Stark <stark@enterprisedb.com>,
	Mario Weilguni <mweilguni@sime.com>,
	valiouk@yahoo.co.uk, Jay <arrival123@gmail.com>,
	pgsql-performance@postgresql.org
Subject: Re: Using PK value as a String
References: <18986.60888.qm@web25807.mail.ukl.yahoo.com>
	<48A15ECF.5030203@sime.com>	<87od3ywg4n.fsf@oxford.xeocode.com>
	<20080812090621.1cafbbab.wmoran@collaborativefusion.com>
In-Reply-To: <20080812090621.1cafbbab.wmoran@collaborativefusion.com>
Content-Type: multipart/alternative;
	boundary="------------040500010500070702070402"

This is a multi-part message in MIME format.
--------------040500010500070702070402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bill Moran wrote:
>> The main reason to use UUID instead of sequences is if you want to be able to
>> generate unique values across multiple systems. So, for example, if you want
>> to be able to send these userids to another system which is taking
>> registrations from lots of places. Of course that only works if that other
>> system is already using UUIDs and you're all using good generators.
>>     
>
> Note that in many circumstances, there are other options than UUIDs.  If
> you have control over all the systems generating values, you can prefix
> each generated value with a system ID (i.e. make the high 8 bits the
> system ID and the remaining bits come from a sequence)  This allows
> you to still use int4 or int8.
>
> UUID is designed to be a universal solution.  But universal solutions
> are frequently less efficient than custom-tailored solutions.
>   

Other benefits include:
    - Reduced management cost. As described above, one would have to 
allocate keyspace in each system. By using a UUID, one can skip this step.
    - Increased keyspace. Even if keyspace allocation is performed, an 
int4 only has 32-bit of keyspace to allocate. The IPv4 address space is 
already over 85% allocated as an example of how this can happen. 
128-bits has a LOT more keyspace than 32-bits or 64-bits.
    - Reduced sequence predictability. Certain forms of exploits when 
the surrogate key is exposed to the public, are rendered ineffective as 
guessing the "next" or "previous" generated key is far more difficult.
    - Used as the key into a cache or other lookup table. Multiple types 
of records can be cached to the same storage as the sequence is intended 
to be universally unique.
    - Flexibility to merge systems later, even if unplanned. For 
example, System A and System B are run independently for some time. 
Then, it is determined that they should be merged. If unique keys are 
specific to the system, this becomes far more difficult to implement 
than if the unique keys are universal.

That said, most uses of UUID do not require any of the above. It's a 
"just in case" measure, that suffers the performance cost, "just in case."

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>


--------------040500010500070702070402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Bill Moran wrote:<br>
<blockquote
 cite="mid:20080812090621.1cafbbab.wmoran@collaborativefusion.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">The main reason to use UUID instead of sequences is if you want to be able to
generate unique values across multiple systems. So, for example, if you want
to be able to send these userids to another system which is taking
registrations from lots of places. Of course that only works if that other
system is already using UUIDs and you're all using good generators.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Note that in many circumstances, there are other options than UUIDs.  If
you have control over all the systems generating values, you can prefix
each generated value with a system ID (i.e. make the high 8 bits the
system ID and the remaining bits come from a sequence)  This allows
you to still use int4 or int8.

UUID is designed to be a universal solution.  But universal solutions
are frequently less efficient than custom-tailored solutions.
  </pre>
</blockquote>
<br>
Other benefits include:<br>
&nbsp;&nbsp;&nbsp; - Reduced management cost. As described above, one would have to
allocate keyspace in each system. By using a UUID, one can skip this
step.<br>
&nbsp;&nbsp;&nbsp; - Increased keyspace. Even if keyspace allocation is performed, an
int4 only has 32-bit of keyspace to allocate. The IPv4 address space is
already over 85% allocated as an example of how this can happen.
128-bits has a LOT more keyspace than 32-bits or 64-bits.<br>
&nbsp;&nbsp;&nbsp; - Reduced sequence predictability. Certain forms of exploits when
the surrogate key is exposed to the public, are rendered ineffective as
guessing the "next" or "previous" generated key is far more difficult.<br>
&nbsp;&nbsp;&nbsp; - Used as the key into a cache or other lookup table. Multiple
types of records can be cached to the same storage as the sequence is
intended to be universally unique.<br>
&nbsp;&nbsp;&nbsp; - Flexibility to merge systems later, even if unplanned. For
example, System A and System B are run independently for some time.
Then, it is determined that they should be merged. If unique keys are
specific to the system, this becomes far more difficult to implement
than if the unique keys are universal.<br>
<br>
That said, most uses of UUID do not require any of the above. It's a
"just in case" measure, that suffers the performance cost, "just in
case."<br>
<br>
Cheers,<br>
mark<br>
<br>
<pre class="moz-signature" cols="72">-- 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc">&lt;mark@mielke.cc&gt;</a>
</pre>
</body>
</html>

--------------040500010500070702070402--