Timeline for Is it good practice to always have an autoincrement integer primary key?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 19, 2016 at 10:02 | comment | added | Ross Presser | /article/title-slug is guaranteed to be unique -- if it wasn't, your site wouldn't know what to serve. Certainly, it has the possibility of changing over time. People misspell slugs. But you couldn't have a more natural key for articles published. | |
| Aug 17, 2016 at 13:43 | comment | added | Matthew Whited | I have no issue with the id. I was really lost on why so many people get their panties in a bunch over it. There is nothing useful with knowing the set of possible PKs. | |
| Aug 17, 2016 at 7:43 | comment | added | Three Value Logic | @MatthewWhited Performance mainly. SQL is a little bit quicker at fetching by an ID or GUID than it is by a title. I actually went with a hybrid system based off of Stack overflow so www.domain.com/article/id/title-slug which seems to work well. For a smaller system I just use the title-slug as you say. | |
| Aug 16, 2016 at 18:58 | comment | added | Matthew Whited | Why are you exposing your URL with a PK anyway? If you want a useful link then do something like www.domain.com/article/title-slug. it say nothing about how much I have in my database and it makes sense for humans trying to remember your blog post. | |
| Aug 16, 2016 at 18:04 | comment | added | Halfwarr | @ThreeValueLogic your hyper link is broken, and is cutting off part of the url | |
| Aug 16, 2016 at 14:19 | comment | added | Karl Bielefeldt | I would add they scale better. Big data NoSQL databases like Cassandra don't even support auto-increment keys. | |
| Aug 16, 2016 at 14:03 | comment | added | Three Value Logic | I said store because that is what I meant. They are created in the database (in this scenario). However there are multiple databases (think test, staging, live). If you generate an incremental ID in the test database how do you know that the live database will generate the same key if it has data in it? There are lots of good reasons to pick an identity. I just wanted to throw out a few for guids based on my experiences. | |
| Aug 16, 2016 at 14:02 | comment | added | Ewan | cant believe the number of people who are stuck in the dark ages using auto inc ints | |
| Aug 16, 2016 at 13:54 | comment | added | Niklas H | You did not say anything about creating IDs in the application - you just wrote "storing". But if it is necessary to create the ID outside the database, then yes, a GUID could be the answer. | |
| Aug 16, 2016 at 13:52 | history | edited | Three Value Logic | CC BY-SA 3.0 | deleted 9 characters in body |
| Aug 16, 2016 at 13:51 | comment | added | Three Value Logic | As for why can't you store the primary id in your application? Because the database creates it. If you run your seeds on an empty database you can assume that the ID will be 1. What if you run the same script on a database with data in it? The ID won't be 1. | |
| Aug 16, 2016 at 13:42 | comment | added | Three Value Logic | Jeff Atwood says it much better than I ever could. blog.codinghorror.com/primary-keys-ids-versus-guids | |
| Aug 16, 2016 at 11:51 | comment | added | Niklas H | -1. A GUID / UUID is not guaranteed to be unique, and is not 100% unique. A GUID is still a finite-length, so at some point you can risk getting a duplicate, although it is highly unlikely. Your point about less trips to the database is also invalid - why can't you store the primary id in the application, as you can with the GUID key? | |
| Aug 16, 2016 at 11:16 | review | First posts | |||
| Aug 16, 2016 at 11:51 | |||||
| Aug 16, 2016 at 11:12 | history | answered | Three Value Logic | CC BY-SA 3.0 |