1

私たちは、新しいアプリケーションのためにデータをモデル化するというジレンマを抱えています。状況はいくぶん複雑です。したがって、私たちの問題と同等の単純化された状況を書き留めます。

  • Web アプリでは、管理者が製品のリストを作成します。特定の製品カテゴリにリンクされたタイトル、説明。など。製品エンティティがあります

  • フロントエンドでは、ユーザーが特定の製品を注文します。そのため、関連付けられた OrderLine エンティティの配列を持つ Order エンティティがあります。各 OrderLine エンティティには、関連付けられた Product があります。

  • 数日後、複数の製品が注文されました。ただし、管理者は製品の価格を変更する必要があります。または、製品が利用できなくなったため、製品を削除することさえあります。

  • データベースには、Products にリンクされている OrderLines に関連付けられた Orders がまだあります。製品が変更される前にデータベースに記録され、変更された製品に関連付けられているデータベース内の注文を管理者が確認するとどうなりますか?

  • 冗長性を可能な限り回避して; データベース レベルでは、そのようなケースをどのようにモデル化しますか?

4

2 に答える 2

2

をモデル化ProductsしOrders、OrderItems同様の方法で; @Neville Kの答えに追加しなければならない唯一のことは、以前にProductPricesドメインエンティティを独自に作成したことです。Product結局のところ、新しい価格を追加することは、新しい を追加することと同じではありません。AProductPriceには、価格、通貨、および開始日と終了日があります。このように価格をモデル化することで、特定の顧客に対してグループ固有の価格や割引を設定することもできます。

于 2012-12-06T10:38:02.783 に答える
1

この問題に対して私が使用した解決策は、「製品」への変更を第一級のドメイン概念として記録することです。通常、これは、注文テーブルに「valid_from」フィールドと「valid_until」フィールドを含め、現在のレコードの「valid_until」日付を now() に設定して変更を記録し、valid_from が now( の製品の新しい行を挿入することを意味します。 ) および null の valid_until です。

これにより、注文が作成された時点の製品情報を注文で取得できます。これにより、ビジネス ロジックでそのデータを推論できるようになります。たとえば、注文が作成された時点の価格を尊重します。

別の方法として、product テーブルに主キーの一部として「バージョン」ID を含め、orderlines テーブルを product_id と version の両方に結合することもできます。

製品を削除しても、SQL "delete" ステートメントになるべきではありません。代わりに、Products テーブルには、製品がまだ入手可能かどうかを示すフラグが含まれている必要があります。製品が利用できなくなったら、製品テーブルの古いレコードに now() の valid_until を設定し、「availableFlag」を false に設定して新しい行を挿入します。

于 2012-12-06T10:21:57.367 に答える