Hacker News Reader

Comment by zackbloom | Hacker News Reader

This is all true, and I'm not here to say the original implementers did anything wrong. As you say though, UUIDs are a general solution, which means they're not going to be optimal for every problem.

View on HN

No, but I think most people overoptimise on the shiny stuff ("oooooh, I saved some bits!") over the important stuff (nasty surprises, several years from now).

Yeah, but sometimes "saving some bits" is really important. It's also really inconvenient to work with UUIDS, like in writing SQL queries etc. The solution these guys came up with obviously works for them.

> It's also really inconvenient to work with UUIDS, like in writing SQL queries etc.

http://www.postgresql.org/docs/8.3/static/datatype-uuid.html makes it look pretty easy…

Precisely the argument from Dilbert's Y2K episode: http://www.tv.com/shows/dilbert/y2k-12015/

How are these eager.io IDs any easier to work with in SQL queries etc.?

UUIDs are optimal for every problem, in that they are unique and fairly fast to generate. There can be no better solution than that, except maybe to save a few bits. And we're only talking about 16 bytes here; not much to complain about. They're cheap at the price.

Yeah its hard to get folks to come into the modern age of computering. FOr some reason there's tremendous resistance to abandoning the old crusty buggy solutions (indexes and handles that collide and need remapping) and using stuff that just works (identifying everything immutable with a uuid). Folks say 'its too many bits' and 'it takes too long'. Then they proceed to write megabytes worth of patchy code to try and save 64 bits worth of identifier.

As for database efficiency, that's a problem. But its a problem with the database - certainly no comfort for the user. But databases could do better, and I think they will one day come to handle uuids with less grief to the developer.

They already do. Postgres and SQL Server have UUID types.

Yeah, exactly. Building weakness into one's protocol because of an unhealthy attachment to saving a few bits and an even more unhealthy attachment to MySQL just seems foolish.

If you work with large amounts of data it hugely matters. 16 bytes times 1 billion records ends up being way more than 16GB of data, indexes, foreign keys, hot backup, etc. to manage and query.

Even that is a small amount of memory. I have that much RAM on my computer. See, its an obsolete conversation, yet folks raised in an ecology of scarcity can't get past it.

It depends on what you are optimizing for. If you need to store your entire database in physical memory, then the difference between 16GB and 128MB is significant.

Reply on news.ycombinator.com