Primary Keys, Unique Constraints and Real-World IDs
A person's name or phone number can change and may not identify one row reliably. This guide gives you a small, testable way to approach the issue before changing a live system.
A practical workflow
- Give each row a stable primary key and put separate unique constraints on true business identifiers.
- Test how nulls, case differences and duplicate imports behave before enforcing uniqueness.
What to check
A synthetic ID does not replace business validation; record what a duplicate means in the domain. Compare the result with the original problem and record what changed. If a measurement or test does not support the change, revisit the assumption rather than adding more complexity.
Keep the experiment small enough to reverse. Document the starting state, the change and the result so another person can repeat the process. Product menus and versions can change, so check the current documentation for your environment.
Official reference: Read the documentation.