1 min readMay 4, 2018
--
It’s a year or so after I have written the article, but I think my recommendations would be:
- if you have a large database or some other reason to physically segment or relocate data to a separate database instance (or will have this), you should use a GUID as the PK.
- For security it’s best not to have anything in a URL that reveals the structure, size, or other internals of your system. So as discussed, using a PK in a URL is generally a bad practice. So use a session key or some other ephemeral mechanism to pass state between requests. A “slug” or some other simple hash value is sufficient to obfuscate.
- If you have a synchronized system — a data lake, data warehouse, or other extracted values, use a GUID as the PK (or use a “secondary PK” approach as described) and confirm that the external system does not depend on the actual numeric PKs.