世界の国やアメリカ合衆国の州など、ルックアップ値を処理するための開発ショップまたはプロジェクトのプロトコルは何なのか知りたいです。
私はそれが 2 つの異なる方法で行われるのを見てきました: 私が作業したある場所では、ルックアップはすべてプレフィックス "L_" を持つデータベース テーブルに格納され、次の列がありました: id、code、desc、ordersequence。たとえば、世界の国の場合、次のようなテーブルがあります。
CREATE TABLE L_Countries(
CountryID INT IDENTITY(1,1) PRIMARY KEY,
CountryCode VARCHAR(10) NOT NULL,
CountryDesc VARCHAR(50) NOT NULL,
OrderSequence INT NULL
)
最近では、ルックアップが列挙型に組み込まれている例を見ました。たとえば、次のようになります。
enum Countries
{
Croatia = 1,
Slovenia = 2,
Serbia = 3,
// and so on
}
これらがデータベース テーブルに由来する場合、列挙用の C# コードを生成するユーティリティがあります。そうしないと、値が変更される可能性が低いという仮定を使用して、時間をかけてすべてのエントリをハードコードするだけです。列挙内の数値については、データベース内の対応するルックアップ テーブルの ID 列に基づいてハードコードされるか、1 から始まるエントリに基づいてハードコードされます。
前者のアプローチについては、コードまたは完全な説明を使用し、順序を操作し、再コンパイルせずに変更を加えるオプションを提供することで、非常に柔軟であるという議論があり、これは確かに私が支持するものです。それらからコードを生成するオプションは可能ですが、大きな利点は、データベースに追いやられても真の「ルックアップ」のままであるということです。最後に、これらの使用方法は柔軟です。Dictionary コレクションの値として、またはサーバー側コードを使用して ASP.NET ListItems または html コンボボックス要素を生成します。
後者について私が聞いた議論は、値は変更されず、アプリケーション レベルでキャッシュされている場合でも、データベースからルックアップ値を取得する必要があるためオーバーヘッドがあるというものです。それらをハードコーディングするか Enum を生成することにより、データベース検索のペナルティなしで利用できます。
私の質問は次のとおりです。
どちらのオプションがあなたにとってより理にかなっていますか、またはあなたの答えが「場合による」である場合、ハードコードされた列挙がアプリケーション全体にわたるデータベース ルックアップよりも優れているシナリオを示すことができますか?
ルックアップを処理するためのエレガントなソリューションである他の方法はありますか? 例として、すべてのルックアップ用の単一のテーブル (「lookupname」列を含む) があるアプリケーションで作業しました。あなたの代替アプローチは、上記の 2 つのアプローチと比較してどうですか?