--- Jim Starkey <jas@...> wrote:

> >Systems without a MAC often use the serial number
> of the BIOS or CPU as
> >the starting point. They are not guaranteed to be
> as unique, but they
> >are the source of the "sufficiently unique" comment
> that non-MAC based
> >methods of computing UUID's are constrained by.
> >
> Who care's about a machine not on a network?

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... :-)

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.

Cheers,
Kevin.




__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs