0

私は少し困惑しました、そして私はSOコミュニティがこれで私を助けることができることを望んでいます。

私は現在、構成可能なルールに基づく注文割引のカスタムロジックを作成している状況にあります。最も単純な形式では、次の表があります。

注文

OrderID int

OrderDiscount

OrderID int
DiscountID int

割引

DiscountID int

Entity Frameworkを使用しています（ただし、この質問はどのデータモデルにも当てはまります）。私のオプションは単純なように感じますが、どちらにも欠点があります。

  1. SQLOrderテーブルに「Discount」列を追加します。欠点：注文が更新されるたびに、割引を再計算してこの列を更新することを忘れないでください。これにより、データの不整合が発生する可能性がありますが、パフォーマンスは向上します。割引額を上書きすることもできます。
  2. コード内の注文データモデルに「割引」プロパティを追加します。欠点：このプロパティにアクセスするたびに計算が必要ですが、常に正確です。

どのルートに行くべきですか、そしてその理由は何ですか？

4

2 に答える 2

1

あなたは2つの重要な会計要件を無視しています

  1. 各注文の割引は、各割引の計算方法の詳細とともに、それぞれの注文に保存する必要があります。注文が GL に送信されると、変更が許可されてはならないためです。投稿された注文はキャンセルまたは取り消すことができますが、変更することはできません。
  2. ただし、注文が作成されているが、まだ GL に送信されていない場合は、ルールが異なります。割引はライブで再計算する必要があります。これは、レコードに保存しないことで最も簡単に実施できます。
于 2013-03-17T16:00:14.167 に答える
0

一般に、データベース内のストーリー計算フィールドは、計算にかかる時間が長い場合を除き、ベスト プラクティスとは見なされません。割引値が変更されるたびに新しい値を格納するのではなく、コンストラクターで計算を実装することを選択しました。この件に関する拡張ビューについては、このリンクを確認してください。 ここ

于 2013-03-17T15:40:06.333 に答える