Change the ids from autoincrements to UUIDs

[JasperHorn]

I couldn't find an issue about this, even though I've thought about a number of times over the years. So, here is an issue.

I have autoincrement integer ids at the moment. Even though they are documented to be opaque strings, I could change them without having a backwards incompatible for the code (well, there is no proper documentation, but if there were, it would definitely state that these ids are opaque strings). It would still be a pretty big change, though. (It would also mean some pretty radical changes to the database schemas of applications...)

I'm not 100% convinced I want to do this yet, but there are some compelling reasons. Most of them stem from the fact that the id can then be created in the code of GoodMemory, instead of in the database.

• Fewer database roundtrips will be needed
• There is less difference between SQL implementations
• A lot of complicated code that is in GoodMemory now is no longer necessary
• It would be easier to support non-SQL storage solutions
• You would never run into an id that is "not yet initialized"
• Exposing them to your users (in a url or api, for example) doesn't unintentionally reveal more information to the world (such as how many items there are in the database, or how fast the data in your database is growing)

There also some drawbacks:

• They take up more storage space. This can add a significant overhead when you consider that they are the thing that also needs to be in each table that "joins" to the table
• Their random distribution can be worse in performance than the incremental distribution of the auto incremented field
• They are too long to remember, which matters mostly to debugging developers

[JasperHorn]

When I first thought of this three-ish years ago, it was just an idea and I was not at all convinced that it was a good idea. In fact, I went back on forth quite a few times on whether this was something I wanted or not.

Now, though, I'm leaning heavily in favor of this change, even if I'm not entirely convinced. That might have crept a bit into my description there.