You might as well timestamp it

Re:You might as well timestamp it by traceroute66 on Saturday April 24, 2021 @06:08AM (#26923731)

> 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

[ Parent | on HN ]

Re:You might as well timestamp it by hk1337 on Saturday April 24, 2021 @07:52AM (#26924242)

You can do both. Use the UUIDs where you need the scalability and serial where you don’t.

[ Parent | on HN ]

Re:You might as well timestamp it by marcosdumay on Saturday April 24, 2021 @10:48AM (#26925239)

> 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).

[ Parent | on HN ]

Re:You might as well timestamp it by gmfawcett on Saturday April 24, 2021 @11:50AM (#26925803)

I'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.

[ Parent | on HN ]

Re:You might as well timestamp it by marcosdumay on Saturday April 24, 2021 @12:20PM (#26926055)

Well, 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.

[ Parent | on HN ]

Re:You might as well timestamp it by twodave on Saturday April 24, 2021 @01:23PM (#26926605)

IMO if you’re going this route, may as well just implement a snowflake clone and get the best of all worlds.

[ Parent | on HN ]

Re:You might as well timestamp it by traceroute66 on Saturday April 24, 2021 @03:33PM (#26927644)

Re: 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.

[ Parent | on HN ]

Re:You might as well timestamp it by twodave on Monday April 26, 2021 @08:52PM (#26950364)

I 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).

[ Parent | on HN ]