3 ms·
I don't get these "usable for 500 years" approaches. If you have an overflow condition you want to encounter (i.e. test) it often. 32bit miliseconds + 96 bit
by j-pb 5y ago
I don't get these "usable for 500 years" approaches.
If you have an overflow condition you want to encounter (i.e. test) it often.
32bit miliseconds + 96 bit of real entropy is brute force resistant, and has a ~50 day overflow period.
That's plenty for eyeball statistics and to make DB indices happy.
Any more sophisticated analytics will require larger precision and timezoning anyways, so don't cram it into the ID and give it it's own field.
Also don't muck with entropy.
All these smart counter schemes are potential attack vectors and have a much higher collision probability.
You're more likely to get a collision due to but flips in such a counting scheme than from two randomly colliding full entropy bitstrings.
- aseipp 5y agoThe intent of these IDs is to be used e.g. as primary keys in a database, and the timestamp improves sortability, helping the database engine pack tuples that are related "in time" into the same pages, which decreases the need for seeks. You can't split the ID and timestamp fields apart; the intent is that they are spatially and temporally related.
- layer8 5y agoYou can use a composite primary key (TIMESTAMP, ID), no strict need to encode the timestamp into the ID.
- j-pb 5y ago> and to make DB indices happy. You can do both, use a low precision timestamp with overflows in the ID to keep the index happy, and add a proper timestamp field for analytics. The 32 + 96 split is what postgres uses for example. I'd say that's a pretty good endorsement.