Padding on timestamp for proper sorting

[maberer]

Is there any specific reason (along making it a bit longer than absolutely necessary) why the timestamp does not contain some padding (beginning zeros)... if it would, I think it could be used as a time order criteria on standard ASCII sorting

[ericelliott]

If you care about this for ID lookup optimization, isn't it possible to customize the sort criteria for ID lookup?

If you care about this to sort entities by creation time, you should have a separate created_at field in your database record and sort on that field, rather than by ID.

In general, an ID should be used strictly as an identifier. I've never encountered a situation where it's a good idea to let the ID serve double duty and be used to encode other information as well. Yes, cuids happen to store creation time, but only incidentally, not as an interface contract, and it's creation time that shouldn't be relied on for accuracy or data validation needs.

[ericelliott]

Rule of thumb (for all IDs, not just cuid): if you're trying to parse the ID to extract any data other than the whole ID itself, you should probably rethink your design.

[maberer]

Thanks for the advice, trying to keep my IDs clean... as a last resort, parts of an ID could be separated e.g. with dashes... some do this by having a shard key combined with the ID so something like:

shardID-CUID ...forming the complete ID

Not sure what your thoughs are with something like that... but I assume that it should be avoided as well.... have seen implementations using something like that.

[ericelliott]

It should be avoided, yes. Not least because different apps have different sharding requirements. For example, some apps shard users or content by region rather than simple bit bucket mapping. Lots of apps mix sharding strategies based on the use case for the specific entity type. It definitely does not make sense to mix sharding concerns into the ID generator itself.

[maberer]

ok thanks

[ericelliott]

:+1: