3 ms·

UUID are ugly, hard to remember in your head, take a lot of space, etc. I favor auto increment IDs any day, except in specific situations. It's worth to consid

by frik 9y ago

UUID are ugly, hard to remember in your head, take a lot of space, etc. I favor auto increment IDs any day, except in specific situations. It's worth to consider to learn how other sites dealt with IDs in public, while internally using auto increment IDs. Short: there are several strategies. But to each their own, if you love UUID, just use it, but don't write lame blog posts how terrible things are.

subway 9y ago
Similarly, if you love auto-increment, use it. Don't write lame HN comments deriding others opinions.
protonfish 9y ago
I always try to use a semantic key first, if it makes sense. For example, I see this in my current database: id utility 1 electric 2 gas 3 water What is the point of the numeric ids versus simply making the name the primary key? I'd argue there is none, plus there significant drawbacks. Every time we start with the utility name and need to get the row id, the database needs to search on a non-primary key. This is going to be commonly used in JOINs (and tables designed with superfluous ids lend themselves to many gratuitous joins.) Optimizing the primary keys based on the typical data used to search (actual key data from the user's standpoint) will make your DB blazing fast. Also, using integers everywhere (or even worse, UUIDs) destroys the readability of queries. How many integer ids could be used in a query and still be understandable? The id `3` could mean almost anything, but the id `water` brings meaning to queries. The benefits to maintainability are significant. Lazy DB designers seem to have a bad habit of adding auto-ids to everything regardless of value. I even see joiner tables (that should be using the composite primary key of multiple foreign keys) using unnecessary auto ids! This is sloppy work. In short, I have found significant benefits to using semantic keys first (if appropriate - there are definitely reasons to use incremental integer or UUID keys in many tables) for these reasons: 1. Fewer columns without loss of meaning 2. Fewer joins needed 3. Faster searches 4. More human-readable
- deleted 9y ago
  [deleted]

by frik 9y ago

subway 9y ago

Similarly, if you love auto-increment, use it. Don't write lame HN comments deriding others opinions.

protonfish 9y ago

I always try to use a semantic key first, if it makes sense. For example, I see this in my current database: id utility 1 electric 2 gas 3 water What is the point of the numeric ids versus simply making the name the primary key? I'd argue there is none, plus there significant drawbacks. Every time we start with the utility name and need to get the row id, the database needs to search on a non-primary key. This is going to be commonly used in JOINs (and tables designed with superfluous ids lend themselves to many gratuitous joins.) Optimizing the primary keys based on the typical data used to search (actual key data from the user's standpoint) will make your DB blazing fast. Also, using integers everywhere (or even worse, UUIDs) destroys the readability of queries. How many integer ids could be used in a query and still be understandable? The id `3` could mean almost anything, but the id `water` brings meaning to queries. The benefits to maintainability are significant. Lazy DB designers seem to have a bad habit of adding auto-ids to everything regardless of value. I even see joiner tables (that should be using the composite primary key of multiple foreign keys) using unnecessary auto ids! This is sloppy work. In short, I have found significant benefits to using semantic keys first (if appropriate - there are definitely reasons to use incremental integer or UUID keys in many tables) for these reasons: 1. Fewer columns without loss of meaning 2. Fewer joins needed 3. Faster searches 4. More human-readable

deleted 9y ago
[deleted]