diff --git a/docs/2022-07-12-uuid-or-else.html b/docs/2022-07-12-uuid-or-else.html new file mode 100644 index 0000000..2b8301e --- /dev/null +++ b/docs/2022-07-12-uuid-or-else.html @@ -0,0 +1 @@ +

UUID or else

There are many use cases where we need to use a unique ID.
In my experience, I only encouter 2 cases:

In my Go universe, there are some libs to help us with this:

First use case is trace ID, or context aware ID

The ID is used only for trace and log.
If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care.
When I use that ID to search log , if it pops more than things I care for, it is still no harm to me.

My choice for this use case is rs/xid.
Because it is small (not span too much on log line) and copy friendly.

Second use case is primary key, also hard choice

Why I don't use auto increment key for primary key?
The answer is simple, I don't want to write database specific SQL.
SQLite has some different syntax from MySQL, and PostgreSQL and so on.
Every logic I can move to application layer from database layer, I will.

In the past and present, I use google/uuid, specificially I use UUID v4.
In the future I will look to use segmentio/ksuid and oklog/ulid (trial and error of course).
Both are sortable, but google/uuid is not.
The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs. \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index e1ad559..a0368ed 100644 --- a/docs/index.html +++ b/docs/index.html @@ -1 +1 @@ -

Index

This is where I dump my thoughts.

\ No newline at end of file +

Index

This is where I dump my thoughts.

\ No newline at end of file diff --git a/posts/2022-07-12-uuid-or-else.md b/posts/2022-07-12-uuid-or-else.md new file mode 100644 index 0000000..ceadacf --- /dev/null +++ b/posts/2022-07-12-uuid-or-else.md @@ -0,0 +1,35 @@ +# UUID or else + +There are many use cases where we need to use a unique ID. +In my experience, I only encouter 2 cases: + +- ID to trace request from client to server, from service to service (microservice architecture or nanoservice I don't know). +- Primary key for database. + +In my Go universe, there are some libs to help us with this: + +- [google/uuid](https://github.com/google/uuid) +- [rs/xid](https://github.com/rs/xid) +- [segmentio/ksuid](https://github.com/segmentio/ksuid) +- [oklog/ulid](https://github.com/oklog/ulid) + +## First use case is trace ID, or context aware ID + +The ID is used only for trace and log. +If same ID is generated twice (because maybe the possibilty is too small but not 0), honestly I don't care. +When I use that ID to search log , if it pops more than things I care for, it is still no harm to me. + +My choice for this use case is **rs/xid**. +Because it is small (not span too much on log line) and copy friendly. + +## Second use case is primary key, also hard choice + +Why I don't use auto increment key for primary key? +The answer is simple, I don't want to write database specific SQL. +SQLite has some different syntax from MySQL, and PostgreSQL and so on. +Every logic I can move to application layer from database layer, I will. + +In the past and present, I use **google/uuid**, specificially I use UUID v4. +In the future I will look to use **segmentio/ksuid** and **oklog/ulid** (trial and error of course). +Both are sortable, but **google/uuid** is not. +The reason I'm afraid because the database is sensitive subject, and I need more testing and battle test proof to trust those libs. diff --git a/posts/index.md b/posts/index.md index ac9a1a4..bbe3841 100644 --- a/posts/index.md +++ b/posts/index.md @@ -5,3 +5,4 @@ This is where I dump my thoughts. - [Backup my way](2022-06-08-backup) - [Dockerfile for Go](2022-06-08-dockerfile-go) - [Bootstrap Go](2022-07-10-bootstrap-go) +- [UUID or else](2022-07-12-uuid-or-else)