diff --git a/docs/2022-07-12-uuid-or-else.html b/docs/2022-07-12-uuid-or-else.html index 2b8301e..28b6141 100644 --- a/docs/2022-07-12-uuid-or-else.html +++ b/docs/2022-07-12-uuid-or-else.html @@ -1 +1 @@ -
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:
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.
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
+
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:
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.
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.
I think about adding prefix to ID to identify which resource that ID represents.