SQLの優れたプラクティスと外部キー

Question

データベース構造を作成する必要があります。

"A"または "B"の2つの異なる文字列値を持つことができるフィールドが必要なテーブルがあります。 それは他のものにすることはできません（したがって、私は文字列型のフィールドを使用することはできません）。

このテーブルを設計するための最良の方法は何ですか：

1）ちょうど2つのレコードが、文字列「A」に1つの文字列のための1つの」と別のテーブルへの外部キーであるint型のフィールドを作成しますB」

2）その後、int型のフィールドを作成して、私のアプリケーションでは、このような列挙を作成

public enum StringAllowedValues 
{ 
    A = 1, 
    B 
} 

3）???

事前に、お時間をいただきありがとうございます。

編集：13分後、私はこの素晴らしいフィードバックをすべて得ます。アイデアと洞察力に感謝します。

Answer 1

多くのデータベースエンジンは、列挙型をデータ型としてサポートしています。実際、列挙が正しい設計ソリューションであるケースがあります。しかし

...

は、別のテーブルへの外部キーが優れていることを決めることができる2つの要件があります。

最初のものは、その列の有効なオプションの数を増やす必要がある場合があります。ほとんどの場合、ソフトウェアデプロイメントなしでこれを実行する必要があります。列挙型は「焼き付けられる」ので、この場合、新しいデータを書き込むことができるテーブルがはるかに効率的です。

第2の点は、アプリケーションが「A」または「B」を超える可能性がある方法で、この列の値について推論する必要があることです。例えば、 "A"は "B"より大きい/古い/より高価かもしれないし、エンドユーザーに提示したいAには他のいくつかの属性がある、またはAは何かのために短手である。

この場合、この知識をクエリに書き込むのではなく、テーブルの列として明示的にモデル化するほうがはるかに優れています。

データベースでの作業の30年間で、私は個人的にBOOLについては何

Answer 2

これらの整数コードの意味を持つ2次表を作成します。 JOINにあなたを強制するものはありませんが、そのデータが必要な場合はそこにあります。あなたのC＃コード内では、まだenumを使って物事を見ても、それをデータベース内のものと同期させようとすることができます。そのうちの1つは信頼できるものでなければなりません。

実際には、短い文字列は厳密な列挙型よりも扱いやすいことがよくあります。コンピュータが遅く、ディスクスペースが不足していた1990年代に、にはがあり、これは妥当なパフォーマンスを得るためのものでした。今は何億もの行を持つテーブルでさえも問題ではありません。