4 ms·
> This is also the reason why serial IDs are way better than UUIDs for internal IDs. There are three core problems with that: a) Serial IDs are a nightmare
by traceroute66 6y ago
> This is also the reason why serial IDs are way better than UUIDs for internal IDs.
There are three core problems with that:
a) Serial IDs are a nightmare for database merges, clustering or anything like that
b) Serial IDs won't scale
c) Serial IDs require management, whilst UUIDs can be produced anywhere (in DB, in frontend etc)
There is the KSUID[1] if people want a time-sortable thing that is near-enough to a UUID.
[1] https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid
- hk1337 6y agoYou can do both. Use the UUIDs where you need the scalability and serial where you don’t.
- marcosdumay 6y ago> Serial IDs won't scale You mean scaling into several machines? Yes, they do scale. Nothing requires that the values are always increasing and have no holes, so you can slice and cluster them at will (and many DBMS do exactly that).
- gmfawcett 6y agoI'm confused? Serial means "always increasing and having no holes" -- it's one thing after the other. What you're arguing for sounds like just IDs, not serial IDs.
- marcosdumay 6y agoWell, by your definition what people use as serial IDs isn't serial. Databases have the concept of sequences, that are closer to your definition, but make no promises about holes (they normally don't generate holes by themselves, but there is no way to guarantee you won't lose numbers upon usage). It is common to use sequences to feed serial IDs, but not all DBMS do that and it's not a requirement in any way.
- twodave 6y agoIMO if you’re going this route, may as well just implement a snowflake clone and get the best of all worlds.
- traceroute66 6y agoRe: Snowflake clone I would humbly invite you to read the note in the KSUID Github, namely: *To fit into a 64-bit number space, Snowflake IDs and its derivatives require coordination to avoid collisions, which significantly increases the deployment complexity and operational burden.* Therefore KSUID remains the best option.
- twodave 6y agoI don't necessarily agree with your conclusion, but I will admit you can't put KSUID and Snowflake in a room and declare either of them the winner. I would argue that doubling your key-space in the case of KSUIDs may have just as much of an impact as coordinating node ids in the case of snowflake (and in fact the snowflake technique only runs into coordination problems when you're at pretty extreme scale).