Timeline for Should you ever not assign an unique ID to each row in a table?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 22, 2011 at 16:24 | history | migrated | from programmers.stackexchange.com (revisions) | ||
| Sep 22, 2011 at 15:21 | comment | added | Dan Ray | Strange that this answer is at -2 currently when it says the same thing the top answer at +7 says... | |
| Sep 22, 2011 at 15:20 | comment | added | Dan Ray | I'm for having a unique key. That should be clear from my answer. In the case of a N:M table, that unique key should be composed from the foreign key fields. That's all I'm saying. | |
| Sep 22, 2011 at 14:42 | comment | added | Jeff O | To a user, they may never search on this id, but once you have isolated a record and want to update it in the db, having a single, no questions asked unique identifier (auto created or not), is a great thing. | |
| Sep 22, 2011 at 14:35 | comment | added | maple_shaft | He wasn't asking about auto-incrementing primary keys but unique primary keys in general, and even if that was the discussion I still disagree with you on principle. | |
| Sep 22, 2011 at 14:32 | history | answered | Dan Ray | CC BY-SA 3.0 |