Home/ Questions/Q 7615941
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T02:46:01+00:00

Which one will you choose as your surrogate key implementation ? Local UUID That

  • 0

Which one will you choose as your surrogate key implementation ?

  • Local UUID
    • That is generated locally in the application, no network trip to retrieve it
    • But the length is long, and can affect the size of your storage size usage
    • Lengthy URL with the long UUID
    • The tiniest fear that UUID collision will happen
  • Or .. Network-unique-counter id (not sure on what is the proper term for this)
    • I imagine a remote Redis with the atomic INC or Mongo with $inc
    • The cost of network trip
    • Is much shorter, takes up less space and resulting in much shorter URL
    • No fear on collision, even on clustered applications
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    For a low concurrency app, you can probably use network counter id.
    But except for url, there is no interest for low concurrency (= not a lot of data).

    In case of heavy concurrency access, so a lot of data, so a lot of clusters, you redis engine + associated network will be probably to slow for this solution.

    In conclusion :
    – network counter seems to be sexy but useless, in my opinion, with MongoDB.

    On MongoDB collision, due to the creation algorithm, the collision is near zero. I explain, a part of the uuid is build with the machine address, which should be unique and you can get this address before putting your cluster in production.

    • 0