Bob, People,
Let me clarify my stance here, because it seems to be getting
misrepresented.
Mark (and Nathan) pushed at repaired UUID type for possible inclusion in
the core PostgreSQL distribution. I'm not opposed to that, provided that
the portability, licensing, and bugs are worked out. Why not? We have
ipv6 data types, after all.
However, Mark went on to suggest that we should recommend UUID over SERIAL
in the docs, and that we could consider dropping SERIAL entirely in favor
of UUID:
---quoth Mark------------------
I suggest that UUID be recommended in place of SERIAL for certain
classes of applications, and that it therefore belongs in the core.
UUID and SERIAL can be used together (although, once you have a
UUID, it may not be useful to also have a SERIAL).
---------------------------------
This was what I objected to; I believe that the use-case for UUIDs is
actually quite narrow and assert that it's a very bad idea to promote them
to most users.
I have a "problem" with SERIAL abuse, too. In general, new DB designers
have come to increasingly believe that surrogate keys (SERIALs, UUIDs,
hash ids etc.) are an intrinsic part of the relational model and a
requirement for all tables. Terrible database designs have resulted,
chock full of tables which lack real keys and cannot be normalized.
UUIDs tend to encourage this sort of behavior even more than SERIALs, not
because of any intrinsic quality in the data type, but because much of the
literature on the subject treats them like some kind of "universal object
identifier" and not distinguishing servers, relations, or real keys.
To repeat, though, this isn't a reason to keep them out of core, but it
*is* a reason not to throw them at newbies as the holy grail of row
identifiers.
For my part, I generally push implementing the UUID concept in a better way
that keeps server, table, and surrogate keys atomic (and thus more useful
and easier to debug).
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco