Geek Answers Handbook

Should I use UUIDs as primary keys for Rails?

I want to use the Spine.js client structure, and it generates UUIDs as identifiers for models that the server can then store. This would be easiest if I just used the created UUIDs for clients for models and saved them on the server.

What are the disadvantages of using client-side UUIDs as primary keys in Rails?

+4
source share
2 answers

I don’t like the UUIDs for the "primary keys" in general, however, the distributed model is one in which they fit quite well, assuming that the UUIDs are generated appropriately ;-) Depending on other problems, there might still be not a primary key, but rather, another candidate key (think of an “alternative PC” that is supported by a unique index).

The two "problems" that I know of are as follows:

  • UUID is like IPv6. They are long and, therefore, are not the most favorable values ​​for humans. On the other hand, they are very consistent in formatting and are easy to spot. You have your copying skills.

  • Completely random UUIDs tend to fragment indexes; if used as a PC, which is usually clustered (compared to an index that can simply point to a record), this can lead to terrible fragmentation. Nonetheless,

    • A good database maintenance plan should solve this problem: rephrase fragmented indexes on a schedule.

    • Special UUID generation schemes, such as NEWSEQUENTIALID in SQL Server , while “more predictable” ones can also generate monotonously increasing values ​​and thus reduce index / cluster fragmentation.

Happy coding.

+11
source

Assuming you are using a relational database to store these values, you need to ensure that the UUIDs usually do not work well as the primary keys of the table when the table is large.

Check out our informative discussion about this blog by our fearless leader: Primary Keys: GUIDs and Identifiers

+3
source

More articles:


All Articles