Draft 03: Mention Surrogate keys and foreign keys

[sergeyprokhorenko]

Surrogate keys are not primary keys in a temporal database. Therefore, it makes sense to mention that the UUIDs described in this specification are good as primary keys and as surrogate keys.

Foreign keys should be mentioned too.

[fabiolimace]

I think UUID v6 and v7 can also be useful for event-driven architectures.

For example, an interface called EventSource exists for server-sent events. The last event ID can be used so that the server only sends events after the given ID.

Some links about event-driven stuff:

• HTTP Feeds spec: Event ID
• Event sourcing
• Event stream processing
• Event-driven architectures

[kyzer-davis]

@sergeyprokhorenko,

The best place to mention this would be part of the Introduction, section 1, second paragraph, first line

Current:

A specific use case for UUIDs which has gained popularity is as database primary keys

Proposed:

A specific use case for UUIDs which has gained popularity is as database primary keys, foreign keys and even surrogate keys.

Let me know what you think.

---

@fabiolimace, I saw your similar comment in another thread. I am not opposed to updating text for another use-case; I just don't know where or how to update the text. Point me in the right direction in Draft 03 and I will give it a stab.

[broofa]

I'd like to see us err on the side of less verbiage, rather than more. Do we really need to enumerate all the different flavors of database keys? Let just remove "primary" from this text.

A specific use case for UUIDs which has gained popularity is as database primary keys

[kyzer-davis]

@broofa, yeah, I was thinking about that approach as well. Abstract it down to "database keys" and leave it at that.