小さなSQLテーブルの主キーとしてUUIDを使用

Question

大きなデータセットのサイズとパフォーマンスの問題のため、UUIDは主キーとしてはお勧めできません。

しかし、いくつかのトップレベルの組織テーブルでそれを使用することは、全く有害でしょうか？例えば。 組織またはブランチ、いくつかのエントリがありますか？

Answer 1

UUIDの代わりにserialを使用することをお勧めします。なぜ整数はUUIDよりも好ましいのですか？

• これらは、より少ないスペースを占有します。これはベーステーブルの中ではわずかな問題ですが、外部キーにとっては大きな問題です。
• 整数は読みやすく、覚えやすくなります。

多くのデータベースでは、テーブルは主キーを使用して物理的に順序付けられています。このようなデータベースでは、UUID上の新しい挿入物はほとんどの場合、レコード間に移動しますが、これは高価です。しかし、Postgresはクラスタ化インデックスをサポートしていないので、基礎となるデータは順序付けされません。

整数に欠点があります。

• 大きなint型はかなりその問題を解決するが、有限の数があります。
• これらは、挿入順序情報をエンコードします。実際には、これは肯定的でも否定的でもあります。

スペースの使用以外は、スタティックテーブルにUUIDを使用することに大きな害はないと思います。私は整数を強く好んでいます。整数を計算するのが難しい状況では、UUIDに頼るだけです。