Encouraging the use of UUID as the primary key

[sergeyprokhorenko]

Encouraging the use of UUID as the primary key

[kyzer-davis]

The database tables SHOULD be marked unsafe if they do not contain UUID as primary key or as part of primary key.

I am not sure this is up to the spec to decide.

[sergeyprokhorenko]

You probably haven't seen chaos in databases with compound business keys. Often, incomplete compound keys are used for relationships between tables, hoping for luck. Such databases are definitely unsafe. UUIDs are designed to displace compound business keys. This is exactly the subject of this specification

[sergeyprokhorenko]

UUIDs are designed to displace compound business keys

UUIDs are designed to provide IDs that satisfy certain key criteria. To the extent such criteria make them preferable to existing solutions is going to be application dependent, and highly subjective (and also changeable over time.)

We should limit opining on best practices and conventions to those issues that affect how well UUIDs meet the stated goals of the spec (uniqueness, monotonicity, db locality). Attempting to reach beyond that just compromises how seriously this spec will be taken.

You arbitrarily put forward the list of goals and demand that other people be limited by them. It is necessary to rely not on non-existent best practices, but on the analysis of real problems that UUID solves.

[sergeyprokhorenko]

Also, what does it mean to mark a database table as "unsafe"? Google doesn't have much to say on the subject, other than MSSQL's TRUSTWORTHY database attribute.

Unsafe mark of table means that database integrity and flexibility are not protected by proper keys. It is similar to package unsafe in Golang that violate type safety. On the contrary the MSSQL's TRUSTWORTHY database attribute is about security, not safety.

[ben221199]

I don't see the need for it. By convention, everbody already uses id as column name and makes it the primary key. For id, somebody can decide to use UUIDs if they want, because it is in the name: UUID.

[broofa]

UUIDs are designed to displace compound business keys

UUIDs are designed to provide IDs that satisfy certain key criteria. The extent to which such criteria make them preferable over existing solutions is going to be application dependent, and highly subjective (and also changeable over time.)

We should limit opining on best practices and conventions to those issues that affect how well UUIDs meet the stated goals of the spec (uniqueness, monotonicity, db locality). Attempting to reach beyond that just compromises how seriously this spec will be taken.

[broofa]

Also, what does it mean to mark a database table as "unsafe"? Google doesn't have much to say on the subject, other than MSSQL's TRUSTWORTHY database attribute.

[sergeyprokhorenko]

The database tables SHOULD be marked unsafe if they do not contain UUID as primary key or as part of primary key.

I am not sure this is up to the spec to decide.

I changed SHOULD for MAY