1

現在の構造は次のとおりです。

Table RowType:    RowTypeID

Table RowSubType: RowSubTypeID
                  FK_RowTypeID

Table ColumnDef:  FK_RowTypeID
                  FK_RowSubTypeID (nullable)

つまり、列定義を行にマッピングしています。場合によっては、これらの行にサブタイプがあり、それらに固有の列定義があります。または、サブタイプに固有の列定義を独自のテーブルから吊るすか、RowType と RowSubType のデータを 1 つのテーブルに結合して 1 つの ID で作業することもできますが、どちらがより良い解決策であるかはわかりません (ほとんどの場合、特定の RowType/RowSubType の ColumnDefs をプルすることになるため、どちらかといえば後者に傾倒します)。

現在の設計は SQL 冒涜ですか?

現在の構造を保持する場合、RowSubTypeID が ColumnDef で指定されている場合、それが RowTypeID で指定された RowType に対応している必要があることをどのように維持しますか? トリガーでこれを強制しようとする必要がありますか、それとも問題を解決する単純な再設計が欠けていますか?

4

1 に答える 1

4

あなたが困っているのは、第四正規形です。

解決策は次のとおりです。

Table RowSubType:       RowSubTypeID
                        FK_RowTypeID
                        UNIQUE(FK_RowTypeID, RowSubTypeID) 

Table ColumnDef:        ColumnDefID
                        FK_RowTypeID
                        UNIQUE(ColumnDefID, FK_RowTypeID) 

Table ColumnDefSubType: FK_ColumnDefID   } compound foreign key to ColumnDef
                        FK_RowTypeID     }   } 
                        FK_RowSubTypeID      } compound foreign key to RowSubType

行サブタイプを持つ列については、ColumnDefSubType テーブルに行を作成するだけで済みます。ただし、すべての参照は制約されているため、異常を作成することはできません。

しかし、それが価値があることについては、オーバーエンジニアリングの可能性に関する@Sethのコメントに同意します。これらの列定義と行タイプをどのように使用しているかはわかりませんが、Inner-Platform Effectアンチパターンのような匂いがします。SQL では、メタデータを使用してメタデータを定義します。データを使用して動的スキーマを作成しようとしないでください。

この優れたストーリーも参照してください: Bad CarMa .

あなたのコメントについて: あなたの場合、Class Table Inheritance または Concrete Table Inheritance を使用することをお勧めします。これは、サブタイプごとに個別のテーブルを定義することを意味します。ただし、元のテキスト レコードの各列は、サブタイプ テーブルのそれぞれの列に入ります。そうすれば、rowtype または rowsubtype テーブルを用意する必要はありません。サブタイプごとにテーブルを定義することで暗黙的に行われます。また、テーブルで定義された列によって暗黙的に指定されている columndefs テーブルは必要ありません。

製品テーブルに対する私の回答、多くの種類の製品、各製品には多くのパラメーターがあるか、私のプレゼンテーション スライドPractical Object-Oriented Models in SQLも参照してください。

于 2010-06-02T17:40:26.653 に答える