Some anti-UUID prejudice and dogma

[sergeyprokhorenko]

I was just confronted with anti-UUID prejudice and dogma based on mindless copying of information technology. These prejudices and dogmas would seem ridiculous if senior IT managers were not guided by them. Therefore, I would like (before it’s too late) to add the following ideas to the section 6.12. DBMS and Database Considerations:

1. Generation is not the only or preferred way to create a UUID. If necessary, UUIDs must be copied. I am talking not only about copying the UUIDs of dimensions or hubs into the fact tables or link/attribute tables associated with them, but also about copying tables along with the UUIDs they contain from one schema or database to another.
2. UUIDs should not be duplicated with human-readable identifiers (codes). However, it is good practice to describe objects denoted by UUIDs if those descriptions are not used as identifiers or for automatic data processing.
3. If UUIDs are used in program code, then it is good practice to add comments to the program code or assign UUID values to variables. However, a more preferable option is to place the UUID along with the business logic in database tables, with the addition of fields that describe the business logic: boolen flags and multivalued conditions of WHEN (SWITCH) control structures.

[danielmarschall]

1. Generation is not the only or preferred way to create a UUID. If necessary, UUIDs must be copied. I am talking not only about copying the UUIDs of dimensions or hubs into the fact tables or link/attribute tables associated with them, but also about copying tables along with the UUIDs they contain from one schema or database to another.

It might be hard to generalize or describe. Maybe mentioning a few examples will make it clear. Like, cloning a customer must generate a new UUID for the cloned dataset. But copying the customer from staging environment to production environment, or recovering a dataset from a backup, must preserve the same UUID.

2. UUIDs should not be duplicated with human-readable identifiers (codes). However, it is good practice to describe objects denoted by UUIDs if those descriptions are not used as identifiers or for automatic data processing.

I don't understand what you mean.

3. If UUIDs are used in program code, then it is good practice to add comments to the program code or assign UUID values to variables.

Agreed. Though it should be variables or constants.

However, a more preferable option is to place the UUID along with the business logic in database tables, with the addition of fields that describe the business logic: boolen flags and multivalued conditions of WHEN (SWITCH) control structures.

Here is an example of a hardcoded UUID in source code: https://github.com/ramsey/uuid/blob/4.x/src/Uuid.php#L70C35-L70C43 This is perfectly fine. Why should this UUID be taken in a database table?

[mcr]

@sergeyprokhorenko The WG might be open to a document with practical guides for using UUIDs, but this is really too much for the existing document. Or maybe write a blog or a book... none of what you write can be normative anyway.

[sergeyprokhorenko]

I don't want to delay approval of the RFC. Therefore I want to close this issue. I hope that the real ridiculous case I described will not be repeated by anyone.