2023-07-18 18:38:30 +00:00
|
|
|
<!doctype html>
|
2022-12-25 19:13:58 +00:00
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<meta charset="utf-8" />
|
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
|
|
|
<link
|
|
|
|
|
rel="stylesheet"
|
2023-12-20 18:45:20 +00:00
|
|
|
href="https://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/5.5.0/github-markdown.min.css"
|
2022-12-25 19:13:58 +00:00
|
|
|
/>
|
2023-04-01 03:37:48 +00:00
|
|
|
<title>haunt98 posts</title>
|
2022-12-25 19:13:58 +00:00
|
|
|
</head>
|
|
|
|
|
<style>
|
|
|
|
|
.markdown-body {
|
|
|
|
|
box-sizing: border-box;
|
|
|
|
|
min-width: 200px;
|
|
|
|
|
max-width: 980px;
|
|
|
|
|
margin: 0 auto;
|
|
|
|
|
padding: 45px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 767px) {
|
|
|
|
|
.markdown-body {
|
|
|
|
|
padding: 15px;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
</style>
|
|
|
|
|
<body class="markdown-body">
|
2023-08-09 07:22:58 +00:00
|
|
|
<h2>
|
|
|
|
|
<a href="index.html"><code>~</code></a>
|
|
|
|
|
</h2>
|
2023-11-19 15:59:21 +00:00
|
|
|
<h1>
|
|
|
|
|
<a
|
|
|
|
|
id="user-content-uuid-or-else"
|
|
|
|
|
class="anchor"
|
|
|
|
|
aria-hidden="true"
|
|
|
|
|
tabindex="-1"
|
|
|
|
|
href="#uuid-or-else"
|
|
|
|
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
|
|
|
>UUID or else
|
2022-12-30 09:26:06 +00:00
|
|
|
</h1>
|
|
|
|
|
<p>
|
|
|
|
|
There are many use cases where we need to use a unique ID. In my
|
|
|
|
|
experience, I only encouter 2 cases:
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
ID to trace request from client to server, from service to service
|
|
|
|
|
(microservice architecture or nanoservice I don't know).
|
|
|
|
|
</li>
|
|
|
|
|
<li>Primary key for database.</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<p>In my Go universe, there are some libs to help us with this:</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="https://github.com/google/uuid">google/uuid</a></li>
|
|
|
|
|
<li><a href="https://github.com/rs/xid">rs/xid</a></li>
|
|
|
|
|
<li><a href="https://github.com/segmentio/ksuid">segmentio/ksuid</a></li>
|
|
|
|
|
<li><a href="https://github.com/oklog/ulid">oklog/ulid</a></li>
|
|
|
|
|
</ul>
|
2023-11-19 15:59:21 +00:00
|
|
|
<h2>
|
2022-12-30 09:26:06 +00:00
|
|
|
<a
|
2023-11-19 15:59:21 +00:00
|
|
|
id="user-content-first-use-case-is-trace-id-or-context-aware-id"
|
|
|
|
|
class="anchor"
|
|
|
|
|
aria-hidden="true"
|
|
|
|
|
tabindex="-1"
|
2022-12-30 09:26:06 +00:00
|
|
|
href="#first-use-case-is-trace-id-or-context-aware-id"
|
2023-11-19 15:59:21 +00:00
|
|
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
|
|
|
>First use case is trace ID, or context aware ID
|
2022-12-30 09:26:06 +00:00
|
|
|
</h2>
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
My choice for this use case is <strong>rs/xid</strong>. Because it is
|
|
|
|
|
small (not span too much on log line) and copy friendly.
|
|
|
|
|
</p>
|
2023-11-19 15:59:21 +00:00
|
|
|
<h2>
|
2022-12-30 09:26:06 +00:00
|
|
|
<a
|
2023-11-19 15:59:21 +00:00
|
|
|
id="user-content-second-use-case-is-primary-key-also-hard-choice"
|
|
|
|
|
class="anchor"
|
|
|
|
|
aria-hidden="true"
|
|
|
|
|
tabindex="-1"
|
2022-12-30 09:26:06 +00:00
|
|
|
href="#second-use-case-is-primary-key-also-hard-choice"
|
2023-11-19 15:59:21 +00:00
|
|
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
|
|
|
>Second use case is primary key, also hard choice
|
2022-12-30 09:26:06 +00:00
|
|
|
</h2>
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
In the past and present, I use <strong>google/uuid</strong>, specificially
|
|
|
|
|
I use UUID v4. In the future I will look to use
|
|
|
|
|
<strong>segmentio/ksuid</strong> and <strong>oklog/ulid</strong> (trial
|
|
|
|
|
and error of course). Both are sortable, but
|
|
|
|
|
<strong>google/uuid</strong> 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.
|
|
|
|
|
</p>
|
2023-11-19 15:59:21 +00:00
|
|
|
<h2>
|
|
|
|
|
<a
|
|
|
|
|
id="user-content-what-else"
|
|
|
|
|
class="anchor"
|
|
|
|
|
aria-hidden="true"
|
|
|
|
|
tabindex="-1"
|
|
|
|
|
href="#what-else"
|
|
|
|
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
|
|
|
>What else?
|
2022-12-30 09:26:06 +00:00
|
|
|
</h2>
|
|
|
|
|
<p>
|
|
|
|
|
I think about adding prefix to ID to identify which resource that ID
|
|
|
|
|
represents.
|
|
|
|
|
</p>
|
2023-11-19 15:59:21 +00:00
|
|
|
<h2>
|
|
|
|
|
<a
|
|
|
|
|
id="user-content-thanks"
|
|
|
|
|
class="anchor"
|
|
|
|
|
aria-hidden="true"
|
|
|
|
|
tabindex="-1"
|
|
|
|
|
href="#thanks"
|
|
|
|
|
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
|
|
|
|
>Thanks
|
2022-12-30 09:26:06 +00:00
|
|
|
</h2>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>
|
|
|
|
|
<a
|
|
|
|
|
href="https://www.cybertec-postgresql.com/en/uuid-serial-or-identity-columns-for-postgresql-auto-generated-primary-keys/"
|
|
|
|
|
rel="nofollow"
|
|
|
|
|
>UUID, SERIAL OR IDENTITY COLUMNS FOR POSTGRESQL AUTO-GENERATED
|
|
|
|
|
PRIMARY KEYS?</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="https://brandur.org/nanoglyphs/026-ids" rel="nofollow"
|
|
|
|
|
>Identity Crisis: Sequence v. UUID as Primary Key</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a
|
|
|
|
|
href="https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html"
|
|
|
|
|
rel="nofollow"
|
|
|
|
|
>Generating good unique ids in Go</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a
|
|
|
|
|
href="https://encore.dev/blog/go-1.18-generic-identifiers"
|
|
|
|
|
rel="nofollow"
|
|
|
|
|
>How we used Go 1.18 when designing our Identifiers</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="https://blog.daveallie.com/ulid-primary-keys" rel="nofollow"
|
|
|
|
|
>ULIDs and Primary Keys</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<a href="https://0pointer.net/blog/projects/ids.html" rel="nofollow"
|
|
|
|
|
>On IDs</a
|
|
|
|
|
>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
2022-12-25 19:13:58 +00:00
|
|
|
|
2022-12-25 19:22:39 +00:00
|
|
|
<div>
|
|
|
|
|
Feel free to ask me via
|
|
|
|
|
<a href="mailto:hauvipapro+posts@gmail.com">email</a> or
|
2023-08-20 17:29:13 +00:00
|
|
|
<a rel="me" href="https://hachyderm.io/@haunguyen">Mastodon</a>.
|
|
|
|
|
<br />Source code is available on
|
2022-12-30 09:55:38 +00:00
|
|
|
<a href="https://github.com/haunt98/posts-go">GitHub</a>
|
2023-08-20 17:29:13 +00:00
|
|
|
<a href="https://codeberg.org/yoshie/posts-go">Codeberg</a>
|
|
|
|
|
<a href="https://git.sr.ht/~youngyoshie/posts-go">sourcehut</a>
|
|
|
|
|
<a href="https://gitea.treehouse.systems/yoshie/posts-go">Treehouse</a>
|
|
|
|
|
<a href="https://gitlab.com/youngyoshie/posts-go">GitLab</a>
|
2022-12-25 19:22:39 +00:00
|
|
|
</div>
|
2022-12-25 19:13:58 +00:00
|
|
|
</body>
|
|
|
|
|
</html>
|
