10 lines
1.6 KiB
Markdown
10 lines
1.6 KiB
Markdown
|
A UUID is amazing. It's almost garunteed that it will always be unique, and makes sense in a lot of use cases, but doesn't lead to a very human readable identifier.
|
||
|
|
It used to be the case that using an auto incrementing integer based ID was the best way to go. It was simple, easy to understand, and hard to screw up.
|
||
|
|
But auto incrementing ID's have a lot of drawbacks when you want something to be unpredictable in order to prevent data leaks. Not only that, but when using sharding, partitioning, or even different databases in the same application, auto incrementing may just plain break your application.
|
||
|
|
|
||
|
|
In came UUID's to fix it, and fix it they did! A UUID is at it's core a 128bit long random identifier. This solves the issues of database partitioning and using different databases in general, but leads to a hard to read ID, not really suitable for things that shouldn't just be machine readable.
|
||
|
|
As an example, this is a UUID: `402b5a52-3751-4daa-bf33-f89b3822d595`. It's stored as a series of 16bytes, represented using hexidecimal characters `0123456789abcdef`, which hyphens to make it more *readable*.
|
||
|
|
|
||
|
|
TinD seeks to solves these issues, by having a customizable length of bytes, that then get's mapped to a list of `runes` or `characters`. An example of a default TinD generated ID is `CBzF`. Much easier to read, much easier to understand.
|
||
|
|
|
||
|
|
TinD doesn't seek to be the most unique identifier in the world. It will not compete at all with UUID's for uniqueness globally, but for a small application, like say invoicing for a small to medium sized company, it provides a balance of uniqueness to readability, with a completely customizable set of characters to use.
|