3

[更新] この質問への回答として、選択したアプローチを以下に示します

やあ、

このテーマについていろいろ調べているのですが、探しているものが本当に見つかりません...

コード テーブルとは、「配偶者の有無」、性別、特定の法的または社会的状態などを意味します。より具体的には、これらのタイプにはプロパティが設定されているだけで、アイテムはすぐには変更されません (ただし変更される可能性があります)。プロパティは、ID、名前、および説明です。

次のテクノロジーでこれらを最適に処理する方法を考えています。

  • データベース内 (複数のテーブル、異なるコードキーを持つ 1 つのテーブル...?)

  • クラスの作成 (おそらく ICode.Name と ICode.Description で ICode を継承するようなもの)

  • このためのビュー/プレゼンターの作成: それらすべてを含む画面があるはずなので、タイプ (性別、婚姻状況など) のリスト、およびそのタイプの値のリストと、それぞれの名前と説明値リストのアイテム。

これらはすべてのプロジェクトに現れるものなので、これらを処理するためのベスト プラクティスが必要です...

記録のために、私はこれらの状況で列挙型を使用するのがあまり好きではありません...ここで列挙型を使用することについての議論も大歓迎です。

[ファローアップ]

わかりました、CodeToGlory と Ahsteele から素晴らしい回答を得ました。この質問を絞り込みましょう。

性別や婚姻状況について話しているのではなく、その値は間違いなく変更されませんが、名前と説明だけを持つ「もの」について話しているとしましょう。例: 社会的地位、法的地位。

UI: これには 1 つの画面だけが必要です。考えられる NameAndDescription タイプのリストボックス (単にそう呼びます)、選択した NameAndDescription タイプの可能な値のリストボックス、選択した NameAndDescription タイプ アイテムの名前と説明フィールド。

これを View & Presenters でどのように処理できますか? ここで、クラス名から NameAndDescription タイプを抽出する必要があるという難しさを見つけましたか?

DB: 複数のルックアップ テーブルと単一のルックアップ テーブルの長所と短所は何ですか?

4

6 に答える 6

2

データベース駆動型コードテーブルの使用は非常に便利です。データの有効期間を定義し（開始日と終了日を使用して）、データをリアルタイムでテーブルに追加してコードをデプロイする必要がないようにし、ユーザーに（もちろん適切な権限で）許可することができます。管理画面からデータを追加します。

コードや説明ではなく、常に自動番号の主キーを使用することをお勧めします。これにより、異なる期間に複数のコード（同じ名前で異なる説明）を使用できます。さらに、ほとんどのDBA（私の経験では）は、テキストベースの主キーよりも自動番号を使用します。

コード化されたリストごとに1つのテーブルを使用します。（ある種のマトリックスを使用して）関連しない複数のコードをすべて1つのテーブルに入れることができますが、それは面倒になり、それがさらに役立つ状況をいくつか見つけました。

于 2009-04-15T20:31:16.260 に答える
1

ここにいくつかのことがあります：

  1. 明示的に明確で変更されない列挙を使用します。たとえば、婚姻状況、性別などです。

  2. 上記のように固定されておらず、時間の経過とともに変化、増減する可能性がある項目については、ルックアップ テーブルを使用してください。

データベースにルックアップ テーブルがあるのは非常に一般的です。ビュー/プレゼンテーションで使用できるビジネス層でキー/値オブジェクトを定義します。

于 2009-04-15T20:19:37.910 に答える
1

私はこのアプローチを採用することにしました：

CodeKeyManager mgr = new CodeKeyManager();
CodeKey maritalStatuses = mgr.ReadByCodeName(Code.MaritalStatus);

どこ：

  • CodeKeyManager は DB から CodeKeys を取得できます (CodeKey=MaritalStatus)
  • コードは定数で満たされたクラスであり、文字列を返すため、Code.MaritalStatus = "maritalStatus". これらの定数は、CodeKey テーブル > CodeKeyName にマップされます。
  • データベースには、2 つのテーブルがあります。
    • ID 付き CodeKey、CodeKeyName
    • CodeKeyId、ValueName、ValueDescription を含む CodeValue

DB:

代替テキスト http://lh3.ggpht.com/_cNmigBr3EkA/SeZnmHcgHZI/AAAAAAAAAFU/2OTzmtMNqFw/codetables_1.JPG

クラスコード:

public class Code
{
    public const string Gender = "gender";
    public const string MaritalStatus = "maritalStatus";
}

クラスコードキー:

public class CodeKey
{
    public Guid Id { get; set; }
    public string CodeName { get; set; }

    public IList<CodeValue> CodeValues { get; set; }
}

クラスコード値:

public class CodeValue
{
    public Guid Id { get; set; }

    public CodeKey Code { get; set; }

    public string Name { get; set; }
    public string Description { get; set; }

}

私はこれまでで最も簡単で効率的な方法を見つけました。

  • すべてのコード データを同じ方法で (同じビュー/プレゼンターで) 表示できます。
  • 今後登場するコードテーブルごとにテーブルやクラスを作成する必要はありません
  • しかし、データベースから簡単に取り出して、CodeKey 定数で簡単に使用できます...
  • Hibernate もこれを簡単に処理できます

私がまだ考えている唯一のことは、GUID ID を破棄し、ビジネス ロジックで使いやすくするために文字列 (nchar) コードを使用することです。

答えてくれてありがとう！このアプローチについて何か意見があれば、どうぞ！

于 2009-04-15T22:55:54.650 に答える
0

なぜ誰もがコードテーブルを複雑にしたいのですか？はい、たくさんありますが、シンプルなのでそのままにしておいてください。他のオブジェクトと同じように扱ってください。これらはドメインの一部であるため、ドメインの一部としてモデル化してください。特別なことは何もありません。必然的により多くの属性や機能が必要にならない場合は、現在それを使用しているすべてのコードを元に戻し、やり直す必要があります。

もちろん、1つのテーブル（参照整合性のため、およびレポートに使用できるようにするため）。

クラスの場合も、もちろん1つです。これは、「Gender」オブジェクトを受け取るメソッドを作成した場合、誤って「MarritalStatus」を渡したくないためです。コンパイルがランタイムエラーを取り除くのに役立つようにしましょう。それがそこにある理由です。各クラスは、CodeTableクラスなどを単純に継承または含むことができますが、それは単なる実装ヘルパーです。

UIの場合、実際に継承されたCodeTableを使用している場合は、それを使用して1つのUIで管理することができると思います。

原則として、データベースモデルを台無しにしないでください。ビジネスモデルを台無しにしないでください。ただし、UIモデルを少し混乱させないでください。それほど悪くはありませんが、

于 2011-03-05T04:49:51.230 に答える
0

私はこのタイプのデータにテーブル表現を使用することに傾倒しています。最終的に、データをキャプチャする必要がある場合は、データを保存する必要があります。レポートの目的で、キーを介してそのデータを引き出すことができる場所を用意することをお勧めします。正規化の目的で、多目的ルックアップテーブルよりも単一目的ルックアップテーブルの方が簡単だと思います。

とはいえ、性別など、変わらないものには列挙がかなりうまく機能します。

于 2009-04-15T20:24:05.157 に答える