Timeline for Why not expose a primary key
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 10, 2020 at 10:20 | comment | added | Michael Durrant | Using a private surrogate key | |
| Nov 10, 2020 at 5:55 | comment | added | user2652379 | I know this is an old answer, but... What are the alternatives to exposing PK? | |
| Aug 28, 2017 at 22:16 | comment | added | Adam Tolley | tl;dr: because the future. If something external comes to rely on a key, things get messy if implementation changes later on; so keep them more or less hidden to make things easier. | |
| Aug 28, 2017 at 19:26 | comment | added | JimmyJames | Great answer. My shorthand way of saying this is that surrogate keys are useful because no one cares about them and no one therefore cares if you change them or don't change them. If you expose them, people will start to care about them. | |
| Nov 18, 2013 at 18:31 | comment | added | Matt | +1 exposing it to users adds implicit requirements (e.g. remain static) | |
| Nov 14, 2013 at 12:37 | history | edited | Michael Durrant | CC BY-SA 3.0 | added 120 characters in body |
| Nov 14, 2013 at 12:35 | comment | added | Michael Durrant | +1 I thought the account number would be the surrogate key but I read up on it and you are 100% correct :) | |
| Nov 14, 2013 at 4:33 | comment | added | nvogel | +1 but what you are describing here is actually a surrogate key. Not every table has a surrogate key and even if it does the surrogate may not be the "primary" key. | |
| Nov 13, 2013 at 19:09 | history | answered | Michael Durrant | CC BY-SA 3.0 |