ルックアップテーブルのベストプラクティス：DBテーブル...または列挙型
会社（マネージャ、チームリードなど）で利用可能なポジションを保存する必要がある場合。それを保存するためのベストプラクティスは何ですか？私はコメント付きの2つの意見を持っています...「確かに、あなたを歓迎します」
- IDとNameの列を持つDBテーブルとして保存し、クエリと結合を使用して処理します。
- それをEnumとして保存し、DBテーブルを忘れます。
私の意見では、アイテムを変更する場合は、最初のソリューションを選択します。これらのオプションをEnumとしてハードコーディングしないようにします。
データが変更されないことに疑いがない場合は、列挙型ソリューションを選択できます（たとえば、性別：男性、女性）。
注意： 私は英語でコーディングしていますが、UIカルチャーはアラビア語かもしれません。 Enumソリューションを使用する場合は、カルチャーベースの文字列をプレゼンテーションレイヤーにハードコーディングします。ベストプラクティスの観点からは問題ありません!!!!
あなたの意見を知りたいのですが、私の考えが最も推奨される「ベストプラクティス」に対応しているかどうかを教えてください。
通常、列挙を使用するのは、変更されない明確なアイテムのセットがある場合のみにしてください。原色、または大陸の名前。それ以外の場合、適切に実装された外部キーを持つルックアップテーブルは、ほとんどの場合常に最良のオプションです。
ルックアップテーブルオプションには、単純なID /値の関係用の多数のルックアップテーブルがある可能性のあるバリエーションが考えられます。ドメイン/ルックアップテーブルのペアを使用すると、コーディングがさらに複雑になりますが、必要なテーブルの数を劇的に減らすことができます。この場合、ドメインテーブルが作成されます。
DomainID int identity Domain varchar（255）
およびキー/値テーブル
DomainID int ID int identity Value varchar（255）
したがって、他の方法で使用する各ルックアップテーブルに対応するドメインテーブルに行が追加され、すべての（キー-ドメイン）/値のペアが値テーブルに追加されます。データベース構造の単純化とは別に、このアプローチには、アプリケーションコードで動的に「ルックアップテーブル」を作成できるという利点もあります。これは、一部のアプリケーションでは非常に便利です。
オプション1：IDとNameの列を持つDBテーブルとして保存し、クエリと結合を使用して処理しますが最低限必要です。
" 避けるべき5つの単純なデータベース設計エラー "から：
アプリケーションによる整合性は開発者に好まれる場合がありますが、DBMSがすべての整合性の集中エンフォーサーである必要があることは事実です。
推奨されるベストプラクティスは、ユーザーインターフェイスについて何も知らないかのようにデータベースを実装することです。つまり、データベースはデータに関連するすべてのルールを適用する必要があります。この場合、データベースは適切な値を適用する必要があります。適切な値を列挙するには、通常、ルックアップ値のタイプごとに lookup table を使用します。多くの場合、アプリケーションは行き来しますが、データベースはそのまま残り、再利用されます。
アプリケーションで列挙を強制したい場合は、確実に行うことができますが、何をする場合でも、データベースがデータベースとして機能し、データの整合性を維持するようにしてください。問題がある場合は、問題を解決してください。あなたは土台を築いています。 「 データベース設計とピサの斜塔 」では、データベースに下地を適切に配置することが非常に重要である理由を説明しています。
これがお役に立てば幸いです。