主キー/外部キーとしてcharを使用していますか？

Question

「国」にリンクするテーブルがたくさんあると考えてください。または「通貨」テーブル。

データを読みやすくするために、国コード（US、GB、AUなど）と通貨コード（USD、AUD）を含むCHARフィールドを、これら2つのテーブルと他のすべてのテーブルの主キーに使用したいforeginキーとしてのこのCHAR。

データベースはinnodbエンジンを備えたmysqlです。

パフォーマンスの問題が発生しますか？避けるべきですか？

Answer 1

パフォーマンスは主な問題ではありません。少なくとも私にとってはそうではありません。問題は、代理キーと自然キーの詳細です。

国コードは静的ではありません。彼らは変化することができ、実際に変化します。国は名前を変更します（例：エチオピアからエリトリア）。彼らは生まれ（例えば、ユーゴスラビアやソビエト連邦の崩壊）、彼らは存在しなくなります（例えば、西ドイツと東ドイツ）。これが発生すると、ISO標準コードが変更されます。

1990年以降の名前の変更：国、都市、その他

これらのイベントが発生してもキーは変更されず、参照テーブルの列のみが変更されるため、代理キーの方が優れている傾向があります。

そのため、代わりにint主キーを使用して国と通貨のテーブルを作成したいと思います。

とは言っても、varcharキーフィールドはより多くのスペースを使用し、膨大な数のクエリを実行しない限りおそらく問題にならないパフォーマンス上のデメリットがあります。

完全を期すために、データベース開発の間違いを参照してください。 AppDevelopersによる。

Answer 2

James Skidmoreのリンクは読むことが重要です。

国コードと通貨コード（それぞれ2文字と3文字）に制限している場合は、char（2）列とchar（3）列を宣言することで大丈夫かもしれません。

それはノーノーではないと思います。 8ビット文字エンコードを使用している場合、それぞれsmallintまたはmediumintのサイズの列を見ています。

Answer 3

私の答えは、明確な答えはないということです。プロジェクト内でアプローチを選び、一貫性を保つだけです。どちらにもプラスとマイナスがあります。

@cletusは、生成されたキーの使用について良い点を示していますが、国コードのようにデータが比較的静的な状況に陥った場合、それらに生成されたキーを導入することは非常に複雑に思えます。現実世界の政治にもかかわらず、国コードの表示と非表示は、ほとんどのビジネス上の問題ではあまり問題になりません（ただし、データが190〜210か国すべてに積極的に関係している場合は、そのアドバイスに従ってください）。

代理キーを普遍的に使用することは、優れた一般的な戦略です。ただし、すべてに自然キーを使用してデータベースをモデル化することに応答することを忘れないでください。了解！ 15年前のデータベースブックを開きます。あらゆる場所で自然キーを使用すると、問題のあるドメインの最初の理解が間違っていることがわかるため、間違いなく困難な状況に陥ります。モデリングのプラクティスに一貫性を持たせたいのですが、明らかに異なる状況に異なる手法を使用しても構いません。

var（2）外部キーでの最新のデータベースのパフォーマンスは、intフィールドと同じ（またはそれ以上）になると思います。データベースは長年にわたってテキストの外部キーをサポートしています。

プロジェクトについて他の情報がないことを考えると、国コードを外部キーとして使用することを好み、そうするオプションがある場合、それは大丈夫だと思います。データの操作が簡単になります。現在の慣行に少し反していますが、-この場合-それはあなたをあるコーナーに戻すつもりはありません。