At 22:50 20/05/2015, you wrote: >Just to chime in here: I think using UUIDs for primary keys is an >absolutely >terrible idea, instead. First off, how are you going to generate them? How >will you avoid collisions? Why should it be necessary to using that much >storage space for a primary key and what's the reason for not using >blazingly-fast integers?...
Agreed. Also the article denounces the "information leakage" introduced by exposing rowids to applications, but keeps quiet about a significant drawback: replacing those integers typically shown in the leftmost column of a grid (which don't forcibly expose meaningful information) by UUIDs is going to eat a very significant screen space if used instead. Finaly I can see many people easily remembering 80486 as an identifier of <something> but almost none able to do the same with their c0b656b1-7351-4dc2-84c8-62a2afb41e66 example UUID. Granted the risk of accidental collision is minimal but still non-zero. Yet their (careful) creation and, moreover, the repeated conversions from 128-bit blob to split hex ASCII for human "convenience" are a useless waste of cycles. To those who say: "UUIDs don't have to be displayed to users", then why complain that INTEGER PRIMARY KEY leak information if they are not displayed either? JcD
