リレーショナル・テーブル設計の問題

Question

ローが変更された場合、どのように履歴リレーショナル・データを保持しますか？この例では、ユーザーはいつでもプロパティテーブルの行を編集できます。テストは任意の数のプロパティを持つことができます。 Propertyテーブルでフィールド 'Name'を編集するか、Propertyテーブルに行をドロップすると、テスト行はテスト時に条件を保持しないことがあります。プロパティ名列を追加し、TestPropertyマッピングテーブルを削除して、Testテーブルのデザインを変更しますか？プロパティ名の列は、文字列の区切りリストのようなものでなければならない。どのように問題が通常処理されますか？

3テーブル：

Test: 
    TestId  AUTONUMBER, 
    Name  CHAR, 
    TestDate DATE 

Property: 
    PropertyId AUTONUMBER, 
    Name  CHAR 

TestProperty: (maps properties to tests) 
    TestId 
    PropertyId 

Answer 1

あなたはプロパティが存在しない場合でも、財産関係を保持する場合。プロパティが必ずしも削除されないようにしますが、プロパティが現在アクティブかどうかを示すフラグを追加します。プロパティの名前が変更された場合は、新しい名前で新しいプロパティを作成し、古いプロパティを無効に設定します。

不活性プロパティを収集する方法を作成する必要があります。

私は、1つの列をコンマで区切られたリストと1対多の関係を模倣するフィールドに決して入れません。 それ以外の場合は、リレーショナルデータベースの目的を無効にします。

Answer 2

Testは、テストの特定のインスタンスのテンプレートとテスト自体の両方として使用されているようです。ユーザーがTestの仕様に従ってテストを実行するたびに、たとえばTestRunという行を作成しますか？これにより、特定のPropertyが保持され、Propertyのエントリが後で変更された場合、次のTestRunに新しい変更が反映されます。

Answer 3

私は質問が完全に答えられたとは思わない。彼らは、プロパティテーブルのフィールド「名前」を編集する場合

...あなたは、プロパティ名の列を追加し、TestPropertyマッピングテーブルをドロップすることによって、テストテーブルのデザインを変更しませんか？

間違いなく。それは目的のために大規模な複製を追加するでしょう。

テスト時にデータの完全性（プロパティ）を維持する必要がある場合、正しい（データベース）メソッドは履歴テーブルを実装することです。これは、ソース表の正確なコピーと、1つの項目でなければなりません。TIMESTAMP列またはDATETIME列がPKに追加されます。

PropertyHistory 
    PropertyId AUTONUMBER, 
    Name  CHAR 
    CONSTRAINT PRIMARY KEY CLUSTERED UC_PK (PropertyId)
 
PropertyHistory 
    PropertyId INT, 
    AuditedDtm DATETIME, 
    Name  CHAR 
    CONSTRAINT PRIMARY KEY CLUSTERED UC_PK (PropertyId, AuditedDtm)

For this to be meaningful and useable, the Test table needs a timestamp as well, to identify which version of ProperyHistory to reference:

TestProperty 
    TestId 
    PropertyId 
    TestDtm  DATETIME

The property names column would have to be something like a delimited list of strings.

That would break basic design rules as well as Database Normalisation rules, and prevent you from performing ordinary Relational operations on it. Never store more than one data value in a single column.

... or drop a row in the Property table

Deletion is something different again. If it is a "database" then it has Integrity. Therfore you cannot delete a parent row if it has child rows in some other table (and you can delete it if it does not have children). This is usually implemented as a "soft delete", an Indicator such as IsObsoleteが追加されました。これは、さまざまなSELECTSで使用されている行を除外して（新しい子を追加するために）参照されますが、既存の子の親として使用できます。