静的データテーブルの設計に関して。次のようなテーブルに静的データを保持します。
すべての外部キー参照がそれを使用するように、別の (INTEGER) 列を主キーとして持つことは理にかなっていますか?
可能な解決策：
_______あなたの提案は何ですか？なんで？
通常はINT IDENTITY列を使用しますが、多くの場合、UI でユーザーに表示するには短いコードで十分です。その場合、クエリの JOIN が 1 つ少なくなります。
ここでは、INT IDENTITY はまったく必要ありません。代わりに 2 桁または 3 桁のニーモニックを使用してください。小さい固有のプロパティを持たないエンティティがある場合は、合成キーの使用を検討する必要があります。しかし、通貨コードと国コードは、それを行う場合ではありません。
私はかつて、誰かが実際に年表を持っていて、各年に YearID があるシステムに取り組んでいました。2001 年は 3 年目で、2000 年は 4 年目でした。これにより、システム内の他のすべてのものが理解しにくくなり、クエリを実行するのが難しくなり、無駄になりました。
ID INT または CHAR を使用すると、どちらの場合も参照整合性が維持されます。
INT の長さは 4 バイトなので、サイズは CHAR(4) と同じです。x<4 で CHAR(x) を使用すると、CHAR キーは INT キーよりも短くなります。x>4 で CHAR(x) を使用すると、CHAR キーは INT キーより大きくなります。短いキーの場合、通常は VARCHAR を使用する意味がありません。後者には 2 バイトのオーバーヘッドがあるためです。とにかく、たとえば 500 レコードのテーブルについて話す場合、INT キーに対する CHAR(5) の総オーバーヘッドはわずか 500 バイトであり、一部のテーブルが数百万のレコードを持つ可能性があるデータベースにとっては面白い値です。
国と通貨 (例) の数が限られていることを考慮すると (せいぜい数百)、実際の通貨はありません。CHAR(4) の代わりに ID INT を使用することで利益が得られます。さらに、CHAR(4) キーはエンド ユーザーにとって覚えやすく、Sql やデータをデバッグ/テストする必要がある場合に便利です。
したがって、通常はほとんどのテーブルで ID INT キーを使用しますが、いくつかの状況では CHAR で作成された PK/FK を使用することを選択します。国、言語、通貨はそのようなケースの 1 つです。