2

Itemグループに入れたいインスタンスがありますItemGroup。ただし、Itemが別のアイテムグループに移動された場合は、説明責任の理由から変更を追跡したいと思います。たとえば、10月Itemに1つ、9月にもう1つあったかどうかを知る必要がありItemGroupます。

これをデータベースでどのようにモデル化する必要がありますか？私のクラス、OOPでこれをどのようにモデル化する必要がありますか？私はいくつかの異なる解決策を見ることができますが、それらはすべて何らかの形で複雑であるため、それを実装する方法がわかりません。

3つのテーブルをItem ItemGroup GroupRelation使用して、タイムスタンプをに保持することもできGroupRelationます。アイテム情報が更新された場合は、新しいアイテムと新しいGroupRelationを作成する必要があります。アイテムがグループを変更した場合、新しいGroupRelationを作成する必要があります。また、グループ情報が変更された場合は、新しいグループと新しいGroupRelationを作成する必要があります。変更時に複数の新しいオブジェクトを作成する必要があるため、複雑です。

Item
+----+---------+-----+------+
| id | item_nr | ean | name |
+----+---------+-----+------+

ItemGroup
+----+------------+-----+
| id | group_name | vat |
+----+------------+-----+

GroupRelation
+----+---------+----------+-----------+
| id | item_id | group_id | timestamp |
+----+---------+----------+-----------+

別の解決策は、クラスItemを2つだけItemGroupにすることですが、両方にタイムスタンプを設定して、いつ変更されるかを知る必要があります。グループが更新された場合、そのグループに属するすべてのアイテムを更新する必要があるため、これも複雑です。

Item
+----+---------+-----+------+----------+-----------+
| id | item_nr | ean | name | group_id | timestamp |
+----+---------+-----+------+----------+-----------+

ItemGroup
+----+------------+-----+-----------+
| id | group_name | vat | timestamp |
+----+------------+-----+-----------+

そして、おそらく他の解決策があります。1つは、古いバージョンを別のテーブルに移動することです。しかし、現在のデータと古いデータの両方を検索する必要があるときにデータを検索するのは複雑です。prev_idまたは、古いバージョンにリンクする列を作成することもできます。

同様のデータモデルの経験があり、推奨事項がある人はいますか？この種の問題のベストプラクティスはありますか？

4

2 に答える 2

3

私はあなたと一緒に行きますItem、ItemGroupそしてGroupRelation最小限の重複で良い正規化されたデザインとして。

監査要件は、監査する必要のあるフィールドとタイムスタンプを保持する、監査する必要のあるテーブルごとに追加のテーブル（例： ItemAudit、 ）を使用してモデル化できます。ItemGroupAudit監査可能なフィールドが変更されるたびに、監査テーブルにデータを入力します。

そうすれば、履歴レコードがあり、履歴データで日々のテーブルを邪魔することはありません。

于 2010-10-04T19:21:40.313 に答える
0

あなたの説明から、GroupRelationHistoryモデルに暗黙的に存在する a の概念があると思います。、 、 のような独自のエンティティItemにItemGroupしGroupRelationます。

オブジェクトの世界では、オブジェクトがオブジェクトへの参照を持っていることを意味するItemその を認識するようにします。本質的には、ゼロ、1 つ、または複数の s の単なるリストです。GroupRelationHistoryItemGroupRelationHistoryGroupRelationHistoryGroupRelation

この概念の導入は、実際のビジネス ニーズに裏付けられている必要があります。顧客 (または担当者) のところに行って、その履歴がそれ自体で存在するものであり、何らかのビジネス価値があるかどうかを尋ねます。はいの場合は、このアプローチについて検討し、ビジネス ニーズに合わせて改良してください。次に、特定の改良に大きく依存するデータベース モデルについて考えてみましょう。そうでない場合は、 Odedが提案したように、履歴の概念を純粋な監査機能にします。

于 2010-10-04T19:57:34.047 に答える