3 ms·

You don't get the cardinality of the data type, just when the object was created. There are probably some business cases where the “when” information is potent

• hot_gril 3y ago
  It's usually benign, but why encode any info into your public IDs? I wouldn't go anywhere near that. It can make sense for some situational internal database use case where you want temporal locality and can't use full sequential since it's distributed, and even then your DBMS might recommend something else, e.g. Spanner explicitly says not to do this. And it doesn't need to be exposed to users.
  • parhamn 3y ago
    Assuming the alternative is a fully random key, this can wreak havoc for performance depending on the database engine and index type used (lots written on this topic). But I do agree, if performance isn't an issue with your db choice and you're not interested in in getting a free "created_at", might as well go fully random.
    • hot_gril 3y ago
      Primary keys have to be chosen carefully because they impact disk layout, joins, etc, and full random makes bad PKs in certain distributed DBs. But it's simple and cheap to convert a public user ID (full random) to/from internal row keys (sequential-ish) at the API boundaries using a secondary index or even a cache.
      • hot_gril 3y ago
        (Like, simple/cheap enough that it's probably worth doing instead of exposing your row keys. Maybe in some careful cases exposing uuid7 row keys makes sense, but not nearly enough to recommend that so broadly. It's not a safe default.)
      • parhamn 3y ago
        Makes sense. Longest HN convo I've managed to keep at this point -- thanks for engaging!