2 ms·

A lot of things that we do for security or privacy are bad for performance, but I think they are still good tradeoffs.

by gls2ro 5y ago

manuelabeledo 5y ago
And for data safety as well. In an environment where millions of events are processed every second, being able to uniquely identify them is a must, and temporal keys are not always an option.
eerikkivistik 5y ago
Agreed. Using UUID-s for keys is useful to exclude entire classes of security issues. Most notable are many kinds of enumeration attacks.
- piaste 5y ago
  Also entire classes of bugs. You screwed up a JOIN, or an application-level lookup for that matter? With UUIDs you'll get no results, with sequential ints you'll get a valid but wrong result. Or worse, the right result for the wrong reason. I've actually seen a case where creating a new entity in the application populated X records in X child tables, each with a sequential ID, and as a result all of them had the same surrogate PK. They were 1:N relationships in principle, but the software wasn't feature complete yet so the actual records were all 1:1. Years later one of those tables finally received some extra records, and it caused a really weird bug because a query had accidentally used the PK instead of the FK as a join key, but for years it had happily chugged along because the two columns were in sync.
- datavirtue 5y ago
  Quit exposing your keys.
tluyben2 5y ago
Yep, so we need solutions for using these practices in a performant way rather than hearing they are not 'good' and then having to explain over and over again why they are there. Our datasets that use UUIDs have not had issues with performance but of course we keep looking for ways to keep using UUIDs while improving performance. It would be better to provide solutions on how to do that and spend time to get performance on par with int keys. Like someone else said; 32 bit int keys are no good anyway for many cases, so let's go to 128 bit, optimize for that and everyone is happy. Edit: like https://news.ycombinator.com/item?id=29851653 https://news.ycombinator.com/item?id=29851653

A lot of things that we do for security or privacy are bad for performance, but I think they are still good tradeoffs.

by gls2ro 5y ago

A lot of things that we do for security or privacy are bad for performance, but I think they are still good tradeoffs.

And for data safety as well. In an environment where millions of events are processed every second, being able to uniquely identify them is a must, and temporal keys are not always an option.

eerikkivistik 5y ago

Agreed. Using UUID-s for keys is useful to exclude entire classes of security issues. Most notable are many kinds of enumeration attacks.

piaste 5y ago
Also entire classes of bugs. You screwed up a JOIN, or an application-level lookup for that matter? With UUIDs you'll get no results, with sequential ints you'll get a valid but wrong result. Or worse, the right result for the wrong reason. I've actually seen a case where creating a new entity in the application populated X records in X child tables, each with a sequential ID, and as a result all of them had the same surrogate PK. They were 1:N relationships in principle, but the software wasn't feature complete yet so the actual records were all 1:1. Years later one of those tables finally received some extra records, and it caused a really weird bug because a query had accidentally used the PK instead of the FK as a join key, but for years it had happily chugged along because the two columns were in sync.
datavirtue 5y ago
Quit exposing your keys.

tluyben2 5y ago

Yep, so we need solutions for using these practices in a performant way rather than hearing they are not 'good' and then having to explain over and over again why they are there. Our datasets that use UUIDs have not had issues with performance but of course we keep looking for ways to keep using UUIDs while improving performance. It would be better to provide solutions on how to do that and spend time to get performance on par with int keys. Like someone else said; 32 bit int keys are no good anyway for many cases, so let's go to 128 bit, optimize for that and everyone is happy. Edit: like https://news.ycombinator.com/item?id=29851653 https://news.ycombinator.com/item?id=29851653