白話文解說 ULID (Universally Unique Alphabetically Sortable Identifier)
覺得我們的內容實用嗎？ MyApollo 電子報讀者募集中！歡迎訂閱電子報!
先前提到蠻多人會使用 UUID 作為確保唯一性的 Id 欄位使用，不過 UUID 的隨機性會有不可排序的問題，舉個例子來說，上一秒還產生 47 開頭的 UUID 字串，下一秒就可能變成 36 開頭的字串，這就導致像 MySQL 這類的資料庫需要更新多個 pages ，資料量大的時候，新增資料將會出現效率問題。
也由於這個問題，所以有人提出 ULID ，讓 ULID 的產生會按照字典順序排序(Lexicographically Sortable)，除了可排序的特點之外， ULID 還有幾項特點：
- 相容 UUID ，都使用 128 bits
- 支援 millisecond 級別的唯一 Id （如果你的使用量已經超過 millisecond 級別，ULID 就不適合使用）
- URL safe 的編碼方式（方便用於 URL），編碼後只需要 26 個字元，比起 UUID 的 36 字元更短
- 不分大小寫
雖然 ULID 看起來似乎比起 UUID 更好一些，不過 ULID 前面 48 bits 代表時間戳記(timestamp)，所以有可能會導致一些安全性的問題，例如只要知道時間戳記，那麼有心人士只要去產生剩下的 80 bits 就能夠猜中某些 Id ⋯⋯。
另外一個問題是 ULID 不像 UUID 有 RFC 標準，只有一份 GitHub Spec 可供參考，每個套件是否正確實作 ULID 的規格，就看套件作者的良心或者要自己多做些測試才知道⋯⋯。
不過不管使用什麼方法產生 Id ，最好要了解一下方法差異才比較好挑選適合自己應用程式的 Id 。（以前沒查不知道 UUID 作為 PK 會有一些問題⋯⋯😭）