2

まったく異なるプロパティを持つ広範囲のアイテムタイプ（> 200）をホストする基本エンティティ（アイテム）があります。私はクリーンでポータブルで高速なソリューションを望んでおり、mabyには私が知らない名前があるという考えを思いつきました。

ここに行きます：

  • items-entityは、基本クラスフィールドとサブクラスフィールドの追加フィールドを保持しますが、ダミー名は、ItemID、ItemNo、ItemTypeID、int1、int2、dec1、dec2、dec3、str1、str2です。

  • 参照されるitemtype-recordは、タイプの名前と子エンティティ（1：n）を保持します。

  • itemtypefields [itemtypeid、name、type、realfield]の例[53、MaxPressure、dec、dec3]

制限事項：

  • ベースクラスでフィールド要件を見積もるのは難しい
  • 子タイプに基づいてドメイン/チェック制約を追加するのが難しい
  • タグ付きSQLを実際のクエリに変換するためのアプリケーション層が必要
  • 共有属性は異なる「実フィールド」に定義される可能性があるため、一度に1つのタイプのみを照会できます。

3番目の箇条書きの説明：

select ItemNo,_MaxPressure_ from items where ItemTypeID=10 and _MaxPressure_>42
should translate to:
select ItemNo,dec3 as MaxPressure from items where ItemType=10 and dec3>42

（spまたはudfの権利でそれを行うことはできません-またはそれは可能でしょうか？）

しかし、次の利点があります。

  • パフォーマンス
  • CRUD操作のしやすさ
  • アプリケーションレベルでの並べ替え/フィルタリングが簡単です。

さて、名前はありますか？

4

1 に答える 1

8

このアンチパターンは、 One TrueLookupTableと呼ばれます。

リレーショナルデータベースでは、各列を1つの論理型として定義する必要があります。INTやVARCHARのような1つのSQLデータ型を意味するのではなく、最初から最後までその列のすべてが同じ値のセットからのものでなければならず、ある値を別の値と区別できるはずです。

靴のサイズ、平均気温、1インチあたりの糸数を特定のテーブルの同じ列に入れても、それをリレーションと呼ぶことはできません。

基本的に、データベースはデータベースではなく、スプレッドシートになります。

関係とタイプの適切な説明については、SQLやRelational Theoryなど、CJDateのほとんどすべての本を読んでください。

コメントを再確認してください。

初歩的な本について講義したり、半構造化データについて嘲笑したりする前に、もう一度Qを読んでください。

さて、あなたの投稿を読み直しました。

One True Lookup Tableの従来の使用法は、正確には実行していることではありませんが、実行していることはOTLTと同じ問題を共有しています。

ItemType 10の列に「MaxPressure」が格納されているdec3とします。MaxPressureの値に有効な選択肢の固定セットがあり、それらを別のルックアップテーブルに配置して、無効なMaxPressure値を誰も入力できないようにします。

次に、MaxPressuresルックアップテーブルを参照するdec3で外部キー制約を宣言します。問題は、ItemTypeが10の行だけでなく 、すべての行のdec3列に外部キー制約が適用されることです。

その理由は、1つの列に複数の値のセットを格納しているためです。他の種類の制約（一意の制約、チェック制約、NOT NULL）でも同じ問題が発生します。また、ItemTypeごとに正しいデフォルトが異なる可能性があるため（一部のItemTypeにはその属性のデフォルトがないため）、列のDEFAULT値を宣言することもできません。

私がCJ日付の本を参照した理由は、彼が型の明確な定義を与えているからです。それは、等式演算が定義されている名前付きの有限集合です。つまり、ある行の値「42」が別の行の値「42」と同じであるかどうかを判断できます。リレーショナル列では、同じ元の値のセットから取得する必要があるため、これは真である必要があります。テーブルでdec3は、MaxPressureの場合は値「42」を指定できますが、1インチあたりのスレッド数の場合は別のItemTypeの値を「42」にすることができます。したがって、これらは同じ値「42」ではありません。一意の制約がある場合、これら2つの42は重複とは見なされません。外部キーがある場合、異なる42のそれぞれが異なるルックアップテーブルなどを参照します。

あなたがしていることは、有効なリレーショナルデータベースの設計ではありません。

あなたがそれを理解していない限り、リレーショナルデータベースの設計に関するリソースを紹介することに躊躇しないでください。

于 2013-03-21T00:07:43.303 に答える