使用類似短 UUID 的類型作為主鍵有什麼問題？

我正在考慮（在 PostgreSQL v13 上uuid_generate_v4()）為我的高流量表使用 UUID 類型（with ），而其他表使用 Text 類型（作為主鍵）通過使用類似於crypt(now()::text, gen_salt('des'))（短 UUID？）的自動生成。

使用這種類似短 UUID 的類型有什麼問題？它可以被認為是一種好的做法嗎？如果沒有，你有什麼建議？

假設有一個包含各種外鍵（FK）的表，每個 FK 都是一個 UUID 類型，然後當我們打開該表時，我們會看到一個水平拉伸的長表，或者當我們進行 API 呼叫時返回一個對象列表他們的身份證，這並不酷。

我正在檢查 Net 上可用的一些 API 呼叫，它們使用了一些固定長度為 10 個字元的類似短 UUID 的類型，所以我在想，他們如何在沒有任何衝突的情況下獲得該結果？它的性能如何？等等

無論您做什麼，都不要使用文本類型來儲存固定長度的二進制數據。例如，儲存為文本的 UUID 佔用 33 個字節，而 UUID 類型僅佔用 16 個字節。您的“類似短 UUID 的類型”是 13 個字元，儲存為文本時佔用 14 個字節。為了節省 2 個輪空和碰撞的風險，我不會使用它。

引用自：https://dba.stackexchange.com/questions/301148