4 ms·
The 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 a
by aseipp 5y ago
The 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.