62

会社で利用可能なポジションを保存する必要がある場合 (マネージャー、チーム リーダーなど)。それを保存するためのベストプラクティスは何ですか? 私はコメントで2つの意見を持っています...「もちろん、あなたを歓迎します」

  1. 列IDと名前を持つDBテーブルとして保存し、クエリと結合を使用して処理します。
  2. Enumとして保存し、DBテーブルを忘れてください。

私の意見では、アイテムを変更する場合は最初の解決策を選択します。これらのオプションを Enum としてハードコーディングしないようにします。
データが変更されないことに疑いの余地がない場合 (たとえば、性別: 男性、女性)、Enum ソリューションを選択できます。

注:私は英語でコーディングしており、UI カルチャはアラビア語である可能性があります。Enum ソリューションを使用する場合は、カルチャ ベースの文字列をプレゼンテーション レイヤーにハード コードしますが、ベスト プラクティスの観点からは問題ありません!!!!

あなたの意見を知りたいのですが、私の考えが最も推奨される「ベスト プラクティス」と一致するかどうかを教えてください。

4

9 に答える 9

47

通常、原色や大陸名など、変更されない明確な項目セットがある場合にのみ、列挙を使用する必要があります。それ以外の場合は、適切に実装された外部キーを持つルックアップ テーブルが、ほぼ常に最適なオプションです。

ルックアップ テーブル オプションには、単純な ID/値の関係に対して多数のルックアップ テーブルを潜在的に持つ可能性のあるバリエーションがあります。ドメインとルックアップ テーブルのペアを使用すると、必要なテーブルの数を大幅に減らすことができますが、コーディングがさらに複雑になります。この場合、ドメインテーブルがあります

DomainID int ID
ドメイン varchar(255)

およびキー/値テーブル

ドメイン ID int
ID int ID
値 varchar(255)

したがって、他の方法で使用する各ルックアップ テーブルに対応するドメイン テーブルに行が追加され、すべての (キーとドメイン)/値のペアが値テーブルに追加されます。データベース構造を簡素化することとは別に、このアプローチには、アプリケーション コードで「ルックアップ テーブル」を動的に作成できるという利点もあります。これは、一部のアプリケーションでは非常に便利です。

于 2009-01-11T20:27:55.817 に答える
7

データベース オプションにはいくつかの利点があるため、私は常にデータベース オプションを使用します。主な利点の 1 つは、コードを変更せずにルックアップ リスト内の項目の名前/説明を変更できることです。また、多数の小さなテーブルではなく単一のテーブルを使用することにも同意します。これにより、データベースから値を取得する単一のルーチンをコーディングして、メンテナンス コストを削減できます。ルーチンが 1 つあるということは、それをうまく機能させるために、より多くの労力を費やすことができるということです。

上記の Cruachan の回答に加えて、親のない行がドメインを説明する親子関係がある場合は、1 つのテーブルで済ませることができます。ドメインに属するすべてのレコードは、親としてドメイン行を持ちます。

ID           int autonumber -- integer primary key for performance
DomainID     int            -- null for domains
Name         varchar(100)   -- Name of the item
Description  varchar(255)

たとえば、通貨のリストには次のものが含まれます。

 ID    DomainID   Name              Description

 100   NULL       ISO Currencies    List of ISO Currency codes
 101   100        BHD               Bahrain Dinar
 102   100        GBP               British Pound
 103   100        EUR               Euro  
 104   100        USD               US Dollar
于 2009-01-13T17:31:12.740 に答える
5

意味のあるデータ (つまり、ID ではなく名前) を使用した簡単なクエリが可能になるため、私はデータベース オプションを使用する傾向があります。

値が変更されないことがかなり確信で​​きる場合は、アプリケーションでそれらを列挙します。また、アイテムの ID を覚えておく必要がなく、コードがはるかに読みやすくなるため、開発がはるかに簡単になります。

このアプローチにより、ルックアップ テーブルをクエリに含めるかどうかを選択できます。たとえば、ルックアップ値を表示したいレポートクエリに含めますが、代わりに列挙から推測できる場合は、アプリケーションにデータをロードするときに含めない場合があります。

明らかに、値が変更または変更される可能性がある場合、列挙は不可能な場合があります。

UI 文化の影響を判断できるのはあなただけです。私はユーザーの文化について 100% 確信しているので、あまり心配する必要はありません :)。

于 2009-01-11T20:08:09.070 に答える
2

私はほとんどの場合、このようなものをテーブルに置く傾向があります。たくさん必要な場合はキャッシュします。それらのいくつかをプログラムで参照する必要がある場合は、ルックアップアイテムのキー値に値が設定された列挙型を作成します。

たとえば、代理主キー（通常、データアクセス層が見た目に追加/更新できないようにするため）、アイテムの値のフィールド、および「候補」（必須ではないため、候補は引用符で囲まれているため、一意です）またはnull）。そうすれば、引用符で囲まれた列挙型を使用して、テーブル内の特定の/重要なアイテムを参照できますが、エンドユーザーが新しいアイテムを追加できる柔軟性があります。使用されるデータモデルの詳細は、実際にはあなたの好みによって異なります（「候補」フィールドを真の主キーとして使用するだけでなく、今私に向かって叫んでいる人もいます）。

于 2009-01-11T21:35:15.153 に答える
2

ルックアップ、ルックアップ、ルックアップ（ここに猿のダンスビデオを挿入）

私の個人的な「ベストプラクティス」は、すべてをデータベースに保存することです。会社のポジションは間違いなくルックアップテーブルです。

同じことが変換にも当てはまります。これは少し難しいかもしれませんが、一般に、テーブルを変換テーブルに結合するビュー定義は良いスタートです。

さらに、Positionがint値のみであり、アプリが単一言語である場合は、位置のタイトルをデータベースに直接追加できます。

于 2009-01-11T20:14:11.883 に答える
2

私は一般的に両方を好みます。テーブルは、レポート、SQL クエリ、およびその他の目的で tableau などのツールに使用できるため、dal レイヤーでテーブルを使用します。

フロントエンドとビジネスレイヤーで列挙型を使用するのは、開発が簡単で、dal からリストを取得する必要も、テーブルの値を覚える必要もないためです。

リストがテーブルと列挙型で同じ場合、C# は列挙型を対応する ID に自動的に変換します。

MVC では、ビューで @Html.EnumDropdownListFor() として列挙型でドロップダウンを使用できるため、ドロップダウンのためにデータベース自体をヒットする必要はありません。

于 2018-04-17T21:57:19.367 に答える
0

それらを同期させておくことができれば、両方を持たない理由はあまりないと思います。DB ストアを使用してステート マシン機能を開発していたとき、IDE 内で使用可能なオブジェクトの状態を列挙することが非常に簡単になりました。

IDE 内で直接選択した DB タブレットの ID 列と DESC 列から C# で Enumeration コード スニペットを作成する EnumGenerator Visual Studio アドインを少し前に書きました。VS Addins を使ったのは初めてだったのでリリースしていませんが、かなりジャンキーでしたが、アドイン/コード生成の経験がある人ならアイデアを取り入れて実行できるはずです。

于 2009-03-18T19:09:06.480 に答える