Re:Database IDs Have No Place in URIs (2008)
by adjkant on Friday May 10, 2019 @10:16AM
(#19877892)
Not if you don't start at zero, and no one knows where you started. Heck, add a multiplier for use in URL's even. It's not hard to come up with reversible obfuscation functions that would hide your number of users for 99.99% of cases. If you have a competitor that set on knowing your count of whatever objects then maybe you have a case. But let's say this is number of posts, clearly viewable on the website anyways. Who cares? If that sort of info is exploitable, you have to have much bigger security holes present.
[ Parent
| on HN ]
Re:Database IDs Have No Place in URIs (2008)
by knodi123 on Friday May 10, 2019 @01:37PM
(#19880204)
> Not if you don't start at zero, and no one knows where you started.
Yes, in fact - even then. There are fascinating historical stories about lay-people who scoffed and then failed to account for the dark art of statistics. https://www.statisticshowto.datasciencecentral.com/german-ta...
At the point where you're doing all of that obfuscation, wouldn't it be easier and safer to use something like a uuid?
So you rather your DB performance tank because of unsortable and unclusterable (sp?) PKs than expose a tiny bit information that shouldn't even be that important? You can use a UUID as a URI link, but you shouldn't use it as a PK on most databases. That means you would have to add another column for the link ID (which I think is a relatively good and clean solution)
Use an encoded time prefix and a random part to create your UUID. I've been using such UUIDs as primary keys in Postgresql for years and I can't tell the difference in performance with say 64-bit numbers. If you don't need millions of records, even a 64-bit number with timestamp and random part will do – like "Twitter snowflake" ids.
Postgres doesn't have issues with UUIDs as primary keys; they don't need to be sorted (hash indexes were dicey before Postgres 10 but are just fine today) and Postgres doesn't row-cluster by default.
What performance cost there is (and in my experience it is not much) is because a UUID is twice as large as a bigint. And there are situations where that matters. But not that many of them.
Re:Database IDs Have No Place in URIs (2008)
by anarazel on Friday May 10, 2019 @05:57PM
(#19882637)
Hash indexes can't be used for primary keys:
postgres[7878][1]=# SELECT amname, pg_indexam_has_property(oid, 'can_unique') FROM pg_am WHERE amtype = 'i';
┌────────┬─────────────────────────┐
│ amname │ pg_indexam_has_property │
├────────┼─────────────────────────┤
│ btree │ t │
│ hash │ f │
│ gist │ f │
│ gin │ f │
│ spgist │ f │
│ brin │ f │
└────────┴─────────────────────────┘
(6 rows)
Huh, so it is. And looking at our schema, it looks like the UUID/hash tables we've got don't use pkeys at all.
Looks like I have a conversation to have. Thanks. :)
Re:Database IDs Have No Place in URIs (2008)
by spinningarrow on Friday May 10, 2019 @05:03PM
(#19882211)
Why shouldn’t you use a uuid as a primary key on most databases?