3 ms·

The person you're replying to didn't even mention those advantages though! The ones they did mention are more significant to me. Of your disadvantages... if I

The person you're replying to didn't even mention those advantages though! The ones they did mention are more significant to me. Of your disadvantages... if I wanted to know when rows were created, I'd just add a created timestamp column. But "easier to read" is for real -- it's easy when debugging something to have notes referencing rows 12455 and 98923823 or in some cases even keep them in your head. But UUIDs are right out. And you definitely don't want to put UUIDs in a user-facing URL -- which is actually how you get around "avoids people being able to just iterate through records", really whether you have UUIDs or numeric pks I think putting internal PK's in URLs or anything else publicly exposed is a bad idea, just keep your pks purely internal. Once you commit to that, the comparison between UUIDs vs numeric as pks changes again.

Semaphor 5y ago
> I think putting internal PK's in URLs or anything else publicly exposed is a bad idea Why? Both as a user and as a dev I love that I can just change the PK to get to a specific post, item, whatever instead of changing the whole link.
- jrochkind1 5y ago
  I mean, the links are going to be a template either way, so you can change the identifier part to change the item; it's just a question of whether the identifier portion is the internal rdbms PK, or something else. It's considered undesirable because it's basically an "implementation detail", it's good to let the internal PK change without having to change the public-facing URLs, or sometimes vice versa, when there are business reasons to do so. And then there are the at least possible security implications (mainly "enumeration attacks") and/or "business intelligence to your competitors" implications too. But it's true that plenty of sites seem to expose the internal PK too, it's not a complete consensus. Just kind of a principle to separate internal implementation from public interface. Here's a short 2008 HN discussion on it, in which people have both opinions: https://news.ycombinator.com/item?id=19876901 https://news.ycombinator.com/item?id=19876901 Here's a more recent and lengthy treatment: https://czep.net/21/obfuscate.html https://czep.net/21/obfuscate.html
  - Semaphor 5y ago
    Thanks, especially those links are helpful, will read through it :)

Semaphor 5y ago

> I think putting internal PK's in URLs or anything else publicly exposed is a bad idea Why? Both as a user and as a dev I love that I can just change the PK to get to a specific post, item, whatever instead of changing the whole link.

jrochkind1 5y ago
I mean, the links are going to be a template either way, so you can change the identifier part to change the item; it's just a question of whether the identifier portion is the internal rdbms PK, or something else. It's considered undesirable because it's basically an "implementation detail", it's good to let the internal PK change without having to change the public-facing URLs, or sometimes vice versa, when there are business reasons to do so. And then there are the at least possible security implications (mainly "enumeration attacks") and/or "business intelligence to your competitors" implications too. But it's true that plenty of sites seem to expose the internal PK too, it's not a complete consensus. Just kind of a principle to separate internal implementation from public interface. Here's a short 2008 HN discussion on it, in which people have both opinions: https://news.ycombinator.com/item?id=19876901 https://news.ycombinator.com/item?id=19876901 Here's a more recent and lengthy treatment: https://czep.net/21/obfuscate.html https://czep.net/21/obfuscate.html
- Semaphor 5y ago
  Thanks, especially those links are helpful, will read through it :)