Integer indexes will also take much longer to become too big to fit in memory, which may affect the performance of your application down the line. Integer ID's are much easier to index and scan due to the fact that they are sequential values. Speed is also a concern when it comes to UUID's. As great as that is, you will be using 16 bytes per UUID as opposed to 8 bytes per BIGINT ID - or even 4 bytes per INT ID for smaller databases. Luckily, modern database versions (such as MySQL 8) offer the possibility to store UUID's in a compact binary format. That means that the simplest many to many table will be storing 72 characters for every single relationship, and things only get worse if you are using UTF-8.
Your primary keys will not only be stored in the original table, but a copy of it will also get stored in every relation table as well. Regarding storage, UUID usage can start to add up quite a bit. If you are looking for increased performance, UUID's will not give you that. If you don't handle ACL correctly and your security holes are big enough, UUID's will do nothing to protect your application. They are security through obscurity and only make things a bit more difficult. With that being said, UUID's should not be thought as a real security measure. UUID's are not incremented and trying to guess them would simply not work. With UUID's, on the other hand, an attacker would need to have gained knowledge of the UUID of every single user that he intends to attack. That means that a security breach discovered for one user could potentially be applied to all your users with minimal effort. If your API exposes a user's regular auto incremented ID of 2202, it is very easy for an attacker to guess that there's a user 2203, 2204 and so on. UUID's are incredibly hard to guess and therefore slightly safer to use if your plan is to expose your ID's externally. There are however a few key points that you can use as rule of thumb before making your decision. The very short answer is yes, the vast majority of projects will benefit from using UUID's as their primary keys. Troubleshooting values that cannot be easily memorized or communicated across the team is just one of the common points of frustration for young (and not so young) developers.
0 kommentar(er)
