DB列挙vsアプリ列挙vsルックアップテーブル
私たちは最近プロジェクトを開始し、設計プロセス中に、チームメンバーの間でいくつかの議論があります。列挙型を処理する必要があるため、3つの選択肢がありました。
- 列挙型をデータベースの通常の列挙として持つ
- アプリケーション内に列挙があり、データベースから分離されている。アプリレベルでのみ保持します。
- 列挙をDB内のさまざまなテーブルに保存する
どう思いますか、その理由は？私の経験から、結合のコストが本当に問題であることを見たことがないので、3番目を選択します。また、ORMを使用する場合、キャッシングにより、結合のコストはほとんどありません。
2つの反対する視点の間に二分があります
- アプリケーションを再コンパイルせずに新しいアイテムをセットに追加できるようにしますか？これにより、データベースのルックアップテーブルが優先されます。
コンパイルされたアプリケーション内のセットに基づくビジネスロジックはありますか。例えば.
if (Client.ClientType == ClientType.Important) DoSomethingSpecial();これは、アプリケーション内の列挙型を支持します。
あなたはあなたのケースにとってどちらが最も重要であるかを決定しなければなりません。ルックアップテーブルと列挙型の両方を使用すると、セキュリティが大胆に制限されているように見えるかもしれませんが、それらが脱調するとすぐに問題が発生する可能性があります。
リストごとに1つずつ、データベーステーブルをお勧めします。
列挙は、1つ以上の属性の許容値をリストするために存在します。おそらく、データベース内にもこれらの制限を適用したいと思うでしょう。そのためには外部キーが必要であり、それらにはテーブルに列挙が必要です。列挙ごとに1つのテーブルを用意することをお勧めします。これにより、外部キーの定義が簡単になり、意図が明確になります。
テーブルと外部キーがあることは、必ずしもすべての読み取りで結合を意味するわけではありません。列挙型が長期にわたって安定していて、意味のある短いコードがある場合、これらのコードは参照テーブルに伝達されます。北、南、東、西の基本的な方向の列挙があるとします。これらは長期にわたって安定しています。彼らは短く、意味のあるコードを持っています：N、S、E、W。コードを見れば誰でも、コンテキストが与えられた意味を理解できます。したがって、外部キーが1文字のコードを参照するようにすれば、この作業が可能になり、結合を省略できます。対照的に、通常の設計では、列挙テーブルに代理キーがあります。これは通常無意味な数値であるため、人間が理解できる値を返すには結合が必要です。
テーブルに列挙を取得したら、アプリケーションでそれらを繰り返すことは意味がありますか？追加のコードとしてそれらを繰り返すのは間違いでしょう。 2つのリストがあり、1つはアプリ内に、もう1つはデータベース内にあります。これらは同期を維持する必要があります。このような重複はエラーの一般的な原因です。列挙型の値が必要になるたびにテーブルを読み取るのではなく、値をアプリケーションにキャッシュしておくと便利です。アプリ、これらの列挙が参照される頻度、使用可能なメモリの容量などによって異なります。値をハードコーディングすることを検討しているため、アプリを再起動してデータベースから新しい値を取得することはできません。他の解決策が可能ですが、問題。
リストが単一値であり、決して縮小されないことが確実である場合、データベース列挙を使用すると機能する可能性があります。列挙値の削除は注意が必要です。新しい値を追加するには、昇格された特権が必要です。追加のプロパティ（例：（方向、コード、方位）=（南、S、180））は使用できません。
どちらの場合も、ストレージのコストがごくわずかな場合は、提案したように、決定要因はおそらく開発と保守のコストに委ねられます。つまり、利用可能なリソースを考慮し、最も単純で最も身近なオプションを優先します。
これらの列挙型を整数値として保存できます。
- 簡単、少ない労力
- 低メンテナンス、データ同期の問題、導入の問題なし
- 追加できます
CHECK MyCol BETWEEN 1 AND 3 - 最高のパフォーマンス
この単純なソリューションが要件を満たしている場合は、それが先の方法です。
Enumテーブルを作成する必要がある場合があります。たとえば、クエリに関連する値が必要になる場合があります。顧客タイプの列挙型があり、顧客タイプごとの最大注文額を使用するクエリが必要な場合があります。次に、そのデータを静的参照データとしてデータベースで使用できるようにしておくと非常に便利です。
これらのテーブルを熱心に作成しないでください。必要に応じて実行してください。整数列から列挙型テーブルソリューションへのアップグレードは簡単です。