Bernd.N wrote:A most interesting thread, and it reminds me on discussions between fellow students in a canteen if Atari is the best computer or not. Most believed that the computer they currently used was the best.
But back to topic. I just googled “uuid performance” and found an interesting article written 2007 from MySQL guru Peter Zaitsev, who made some performance testing where integers were much faster for a large table with 268 million rows (200 times performance difference):
http://www.mysqlperformanceblog.com/200 ... t-to-uuid/
Actually, there are tons of articles for "uuid performance", therefore I think we should not fighting tooth and nail about this theme that others discussed so much already.
As I said earlier, this was a much debated issue 5+ years ago and almost entirely in the context of RDBMs—performance and storage size were definite concerns. The database field since then has seen quite a shakeup. RDBMs are no longer the only game in town and have had to adapt significantly to keep up with solutions offered by other types of databases. For sure, optimizations around PK UUIDs have been improved dramatically.
Bernd.N wrote:Without being aware of this thread, I asked by chance today if I should use an integer at least for the most important tenant_id in each table, while using UUID as PK for all tables in general.
I agree to the advantage of integer PKs for debugging. I had cases where I just asked customers to give me the ID of a record that has a problem on phone. So identifying a record is much simpler. Therefore I am currently planning to use both a UUID as PK and a sequenced integer as user-friendly ID for communication about a specific record. I do not want to horrify my users by showing them a UUID.
To me this sounds more like a case for a custom customer identifier that has a little more meaning than just a sequenced integer. Ex: customer "8472" vs "SVY-012".