On Thu, Oct 8, 2020 at 6:14 AM Hemil Ruparel <hemilruparel2002@xxxxxxxxx> wrote: > I was thinking UUID was not a very good choice for id. Serial would be a better one because I don't have a billion customers. It is more like a thousand. So when I saw the customer ID of the payment gateway cannot accept more than 32 characters, I thought UUID is overkill. So I want to migrate to using a serial int instead as the primary key., I do not like them. They are typically random 128 bit integers. If you think of it, random 16 bits ints are not a good idea for keys, even if the table has only a couple dozen keys. UUIDs are the same at a bigger scale, they look nicer and safer, but have got problems. The version 1-2, the one with mac address with theoretically guaranteed uniqueness were nice for their intended use, avoiding collisions without a central authority. But the namespace hash and random version are practically collision free, but not theoretically, which displeases me. When I need to present an obscured name to an outside service ( i.e., in your case, presenting the user id to the gateway directly leaks information, as they can estimate your consumer growth ) I just encrypt ( not hash, encrypt ) them. For these you can do something like treating a 64 bit number like an 8 byte array, encrypt it with a "secret" key and you send something which is random enough to the gateway, but is easy for you to manage in the database, and preserves the counter niceties, like knowing there are approximately 1000 customers between IDs 3000 and 4000 ( some may have been deleted /skiped ). Also, depending on your patterns, IDs typically correlate nicely with table order, which makes index access a bit faster, you do not jump around. And 4 byte ints make for a much denser index than 16 byte uuid. Francisco Olarte.
