Normalize the UUIDs into one table

from a pure data schema perspective, since uuid is a perfect example of atomic and unique content linked to only one piece of content, hook_schema_alter() is the "right" way to do this.

However, many people resist modifying the schema of the core Drupal tables. I sympathize with this.

I do think the performance might be an issue with a big table. But on the other hand, when you load a node (with attendant comments), you've got two more joins uuid_node, and uuid_comments to add, which is a lot slower.

And as someone pointed out in another thread, with an index on (uuid,node_type), lookups might not be that adversely affected.

From a maintainer, coder, point of view, of course, it would be great to have a uuid module where new types of uuids could be added without having to add to the schema.

I've found a little problem here. Some uuids are stored using more than one key: e.g. node revisions. Allthough every node revision is unique by its node->vid value, uuid_node_revisions table is using both attributes: $node->nid and $node->vid to index the unique uuid. Later on hook_nodeapi, when the 'delete' operation is fired, the node_revisions table is deleted using $node->nid index only, and $node->vid is used to delete a single node's revision.

How will that big table support this issue of using more than one key to index the uuid entries with their respectie bundles (node, node_revisions, users..)?

I also found it strange that there is a separate table defined for each object type. It makes me nervous about the scalability of the module that there are specific implementations for each type. At least the tables could be dynamically made (like content type tables in cck) to represent whatever object is needed.
This is because I may want to create my own Entity in future versions (D7) and have a UUID on it. I would expect the UUID module to handle the storage, and not have to make my own table?

This was recently discussed in the context of the D7 port. There were some concerns about performance using 1 big table. More info in the IRC log.

Let's hit this up in the 7.x branch before backporting to 6.x.

I don't think we need to change to one big table. If it's in relation to #1181982: Add menu hook for linking to UUIDs, I have a suggestion. The lookup paths can always be cached in a table with a structure similar to path alias.

Subscribing.

For D7 we have decided to support entities and so the one big table approach won't work. See #1212954: Proposing generic entity solution, possibly for 1.x.