シンプルなデータを変更しないための外部キーテーブルを作成しますか？数学的操作対説明的なテキストを使用して

Question

私のデータベースに私はのルールテーブルがあります。アプリケーションのユーザーは、さまざまなフィールドを比較できる多数のルールを構築できます。 FieldAがFieldBより大きい。等しくない、より小さい、等間隔で置き換えることができる唯一の条件ではない。

この条件は、自分のルールテーブルに保存する必要があります。 2つのオプションがあります。1つは、それを識別するテキストを含む列を含めることです。データは次のようになります。

Id,Name,FieldId,FieldToCompareId,Condition 
1000,RuleA,2000,2001,GreaterThan 

2番目のオプションは、これらすべての条件で、ルールテーブルの上にFKを持つ、最初のオプションは、最も簡単かつ迅速である。この

ConditionTable   RuleTable 
---------------   ---------- 
Id,ConditionName   Id,Name,FieldId,FieldToCompareId,ConditionId 
1000,GreaterThan   1000,RuleA,2000,2001,1000 
1001,Equals 

ようなもので、外部キーテーブルを作成することです条件の記述が決して変更できないという欠点があります。 2つ目のオプションは、他の列を追加して、たとえば、そのテキストに基づいて自分のアプリケーション内で作業するのではなく、ユーザーに表示されるわかりやすい名前です。

2番目の選択肢の主な問題は、この構造に従う場所が多いため、非常に静的なデータのためにさまざまなテーブルを作成することになり、アプリケーションのデータにアクセスする複雑さが増します。 。

最初のオプションは賢明な解決策ですか、私は常に外部キーテーブルをリファクタリングする必要があるので、テキストの代わりに行内にIDだけを格納していますか？

Answer 1

私は、第2のアプローチが長期的には常にベストのために常に努力していることを発見しました。痛みは設計にありますが、データアクセスロジックを簡素化するためにビューを作成することができます。また、現代のフレームワークとデザイナーは、このデザインをサポートしており、ユーザーインターフェイスを簡単に作成することができます。

オプション1を選択した場合は、他のフィールドを追加して、アプリケーションレイヤーのテキストの解析を避けることができます。

どちらの場合でも、これまでのやり方と似たアプローチをとることができます。別のフィールドにフィールド名と演算子を格納するデザインを作成し、ルールを実行するために動的SQLクエリを作成できるようにしました。私はあなたの両方のオプションは、長期的なビジネスニーズに立つには余りにも堅いと信じNOT IN ...

Answer 2

、IN、等しい、より大きいすることで、その情報を格納していない第三の選択肢は、あり

を変更しますデータベースではなくアプリケーションクラスとして使用します。これは、ルールの実行時更新を許可する必要がない場合、長期的には最高です。

ルールの更新要件が存在する場合、ルールがアプリケーションクラスにテンプレートとして保存され、すべてのルールバインディングのターゲットオブジェクトへのルールの関連付けのみがより一般的なアプローチを使用することをお勧めしますこのような列を持つ単一のテーブルに格納：

RuleId int型 RuleParameters varchar型 TargetObjectType varchar型
TargetObjectIdentier varchar型明らか

、ルールパラメータは、ターゲット0とルール適用パラメータを関連付けるための解析のいくつかの並べ替えを必要と回避する。そして、同じデザインの整合性を守る現実的な選択肢は、

Answer 3

役立ちますことを願っています

長期的にはまだ、（複合キーすることができます）、そのタイプと識別子を使用して、ターゲット・オブジェクトを関連付けるしかし、のために行きますあなたの質問に答える正しい方法は、機能の依存関係を考慮して冗長性を排除することです。最初のソリューションを選択した場合、数学的にRuleAと同じRuleBを追加しないようにするにはどうすればよいですか？それは悪いことだろうか？ RuleAが間違って定義されたり誤用された場合はどうなりますか？ユーザーに別個のルールリストを提示したい場合はどうすればよいですか？ルールの使用を要約したり、特定の種類のルールを防止する場合はどうすればよいですか？

これらの質問は、あなたの宇宙では、ルールの定義が条件での使用とは無関係であることを示しています。そのため、それは独立して（名前によって）識別され、条件によって参照されるべきです。

これも

必ずしも自分のアプリケーション内のデータにアクセスする複雑になります。ビューはその目的のために作成されました。最初のソリューションは、1回の結合で2番目のソリューションから再現できます。