Be aware that the "random" UUID part (everything after the 2nd ``) is rather short and like this not good enough to be used as standalone UUID._
YID creation is slow compared to integer IDs or UUIDs, they are long and comparing them is more costly than comparing UUIDs. Their benefits are that they directly reveal the type of object (which is a massive bonus when debugging or sharing object identifiers) and that they are sortable at every moment, without additional database queries (which can speed up the app a lot).
Any YID can be fed to the search / an endpoint / a disolver service which can then return the actual object (or an error e.g. 403, 404, ...).
YID can be used in URLs, but as they are long and probably funny-looking, you might consider using slugs. The slug should be created by some fast symmetric encoding / decoding encryption algorithm that backends and frontends can use.
Idea
Rather large change, to not use UUIDs for our custom tables, but YIDs (Yournaling IDs) that consist of three parts:
_
underscoresIn this implementation the YIDs have to be generated on the server.
YID - Yournaling ID
YID are sortable unique IDs which contain:
YID are:
yid
as primary keyYID are constructed like this:
user_2023-02-26T09:20:20.075800Z_6511ee876a86
object.klass::YID_MODEL_object.created_at.utc.iso8601(6)_SecureRandom.hex(6)
Any YID can be fed to the search / an endpoint / a disolver service which can then return the actual object (or an error e.g. 403, 404, ...).
YID can be used in URLs, but as they are long and probably funny-looking, you might consider using slugs. The slug should be created by some fast symmetric encoding / decoding encryption algorithm that backends and frontends can use.