1

各項目が製品に関連付けられているドメイン モデルがあります。製品にはオプションのリストがあります。各オプションは、必須またはオプションのいずれかです。ユーザーは、項目の選択リストに追加するオプションのオプションを含めることができます。

冗長性を避けるために、私が最初に考えたのは、必要なオプションを項目の選択リストから除外することでした。多くの必須オプションがあるため、すべての項目にそれらを含めると、データベースが肥大化します。

問題は、製品が時間の経過とともに変化する可能性があることです。かつては必須だったオプションがオプションになる可能性があり、逆もまた同様です。また、まったく新しいオプションが製品に追加される可能性があります。明細項目の選択リストの意味は、注文時の製品のオプションに依存するため、これは私の最初のアイデアに問題を引き起こします。

それで、私は何をすべきですか?

  1. 品目の選択リストに必要なオプションも含めると、モデルは単純になります。製品に含まれていたオプションのスナップショットが欲しいです。しかし、必要なオプションへの参照がすべての項目で繰り返されるため、データベースの肥大化も大きくなります。これは私が心配する必要があることですか、それとも SQL Server がバックグラウンドで何らかの圧縮を行うのでしょうか?

  2. ラインアイテムの選択リストから必要なオプションを除外するという当初のアイデアを追求する必要がありますか? 次に、製品の変更に関する履歴データを保持する必要があります。そうすれば、注文時に存在していた製品とそのオプションを再現することができました. 可能に思えますが、最初のオプションよりも複雑です。より多くの CPU サイクルが必要になるのではないかと心配していますが、頻繁に開かれない古い注文の場合は問題ありません。これまで自分でこれを行う必要はありませんでしたが、それほど難しくはないかもしれません。これがあなたが推奨するアプローチである場合は、私が始めるのに役立つ設計パターンなどへのいくつかの指針を提供してください.

4

1 に答える 1

1

必要なオプションのリストが将来変更される可能性がある場合は、最初のオプションを使用します。これらのオプションを各項目とともにデータベースに保存しない場合は、どのオプションがどの日付に必要であったかを追跡し、それらを個別に結合する必要があります。これにより、結合ロジックが不必要に複雑になります。

データベースの肥大化に関しては、あなたが思っているほど悪くはないと思います。おそらく既に の結合テーブルがProductOptionsありLineItemOptions、プロダクト キーとオプション キーだけが含まれているようです。この後者のテーブルは、最初のデザインの選択に基づいて、より多くのレコードを持つことになる唯一のテーブルです。これにはキーしか含まれていないため、レコードが多くのメモリを消費することはなく、結合も非常に高速です。

于 2012-08-25T16:42:07.880 に答える