Kevin Berry wrote:

>
>
>In my case the requirement has to do with distributed
>systems on isolated LANs i.e. they're not all on the
>same network. The systems will not be installed by
>professionals and hence they should be
>self-configuring and easy to administer. UUIDs
>provide that solution in my case because there is no
>unique setup required. I do not want to assign site
>IDs either. Just install and go... :-)
>
>

Since you don't have a cluster, cluster-unique keys are not going to
work for you.

>I must say that I also dislike compound keys. They
>make complex relationships harder to represent in a
>database (many more compound foreign keys). UUIDs
>allow you to have a single non-composite key for most
>tables in your database while still ensuring that the
>IDs are unique. I've encountered quite a few cases
>where the natural key value has to actually change
>(this always boggles my mind but it's always a
>"business" requirement!!). My solution to this is to
>use a UUID key and then let them change the natural
>key because it is simply a data field (and this
>doesn't require updates to multiple tables). UUIDs
>aren't always the correct solution- sometimes natural
>keys do make more sense of course.
>
>
>

I have long since abandoned the idea of nature primary keys for tables
with more than a single field. Well, not quite true. In fact, I have
to re-learn this every so often. I prefer the simplicity and
performance of sequences, but I also recognize that in a disconnected
network, they're not going to work.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376