Preventing identifier duplication risks
Even if you use UUID's as identifier in your database (like showcased in Unique identifiers), each time you need to use identifiers as keys (for example, in a dictionary field), you are going to face the risk of generating an identifier that is already being used inside your object, which will cause your old data to be overridden if you try to update it to a new value.
If you use pseudo randoms identifiers (like showcased in Unique identifiers your risks of identifier duplications will be extremely low, and the one in a billion chance of overriding data is acceptable compared to the additional database requests required to make sure you are not at risk of overriding data.
However, for crucial operations where identifier duplication and overriding data due to an id duplication would be catastrophic (for example, creating a project inside an account, where an identifier duplication would cause the previous project to de deleted), you should check that the identifier does not exist before creating your new field.
If you perform operation inside an account where the risk of erasing data would not be catastrophic (for example, adding a new item into the shopping cart of an user, where the worst case if a duplicate id is generated, is to override and remove another item present in the cart), you can perform operations without worrying about id duplication.
You can do that by simply trying to retrieve the field you will be targeting before trying to update it, and only update the field if the value you retrieved is None (hence, not found).
#
Simple example#
Complete bulletproof exampleYou could also go one step beyond, aim to be bulletproof, and prepare for the occurrence of an identifier duplication, by allowing multiple attempts to generate an identifier that is not already used.
Read more at : https://en.wikipedia.org/wiki/Universally_unique_identifier