Bernd.N:
david:
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. … For sure, optimizations around PK UUIDs have been improved dramatically.I currently use a SaaS solution for project management. And it needs about 5 seconds to just load one single task.
For me, such delay reduces the ability to really work fast and efficient, and I would not want my own users to wait so long until a record appears.
Therefore, I appreciate any method to improve response time performance for users.
And we have to keep in mind that not only RDBMs-performance improved much, but also data size and traffic.
Right. But, 5 seconds to load one single task has nothing to do with UUIDs vs auto-incrementing integer PKs. Crap programming/multiple round trips, slow connection, throttled server, missing indexes, Servoy web client, etc. This supports my point: UUIDs are the least of your performance worries in today’s typical business apps. And if you don’t use them, you are missing out on a ton of programmer ease-of-use and a major feature of the current web landscape: data ubiquity across services.
Whenever we run across auto-incrementing integer PKs, we literally cringe. Automatically puts your data in a restrictive box.