We are currently developing an API for our product. The API offers access to a graph consisting of relationships between types, such as users, messages, etc.
Now these objects refer to the primary key identifier in our database, but since each object is in a different table, these identifiers collide without information about the type of object (= table).
This may not seem like a problem, but it is valid for us - the design of the API is becoming much more incompatible with these identification collations / type of information in the wrong place.
Now the idea is to use UUIDs, and since we are likely to move from SQL db to K / V storage in the future, this may not be the worst idea, also UUIDs offer much better uniqueness and also scale better. Thus, the implementation of the UUID in our API will not be the worst thing from different points of view.
However, for the transition period, we still need to access the objects using the DB identifier, and the UUID must be generated from the identifier and allow the identifier to be displayed from the UUID vice versa.
It occurred to something like 550e8400-e29b-11d4-YYYY-XXXXXXXXXXXX, where X will be the main database key, and YYYY will be the code for the type of object.
Is there a “right” way to do this? Can I break anything with this approach? Saving additional UUID information in whole or in part is not an option.
Thanks for your understanding, Philip.