「countries」または「currencies」テーブルにリンクするテーブルがたくさんあると考えてください。
データを読みやすくするために、国コード (US、GB、AU など) と通貨コード (USD、AUD) を含む CHAR フィールドをこれら 2 つのテーブルのそれぞれの主キーにし、他のすべてのテーブルはこの CHAR を次のように使用します。外国の鍵。
データベースは innodb エンジンを搭載した mysql です。
パフォーマンスの問題が発生しますか? それは私が避けるべきものですか？
少なくとも私にとっては、パフォーマンスは実際には主要な問題ではありません。問題は、代理キーと自然キーに関するものです。
国コードは静的ではありません。彼らは変化することができ、実際に変化します。国の名前が変わります (例: エチオピアからエリトリア)。それらは発生し (ユーゴスラビアやソビエト連邦の崩壊など)、存在しなくなります (西ドイツや東ドイツなど)。これが発生すると、ISO 標準コードが変更されます。
1990 年以降の名称変更の詳細: 国、都市など
これらのイベントが発生した場合、キーは変更されず、参照テーブルの列のみが変更されるため、代理キーの方が優れている傾向があります。
そのため、代わりに int 主キーを使用して国と通貨のテーブルを作成する傾向があります。
そうは言っても、varchar キー フィールドはより多くのスペースを使用し、膨大な数のクエリを実行しない限り、おそらく問題にならない特定のパフォーマンス上の欠点があります。
完全を期すために、AppDevelopers によるデータベース開発の間違いを参照することをお勧めします。
James Skidmore のリンクは重要です。
国コードと通貨コード (それぞれ 2 文字と 3 文字) に制限している場合は、列 char(2) と char(3) を宣言することで問題を解決できる可能性があります。
それはノーノーではないと思います。8 ビット文字エンコーディングを使用している場合は、それぞれ smallint または mediumint のサイズの列を見ています。