我有一个域模型,其中每个订单项都与产品相关联。该产品有一个选项列表。每个选项都是必需的或可选的。用户可以添加一个可选选项,将其添加到行项目的选择列表中。
为了避免冗余,我首先想到的是从订单项的选择列表中排除所需的选项。有很多必需的选项,因此为每个订单项包含它们会导致数据库膨胀。
问题是产品可能会随着时间的推移而发生变化。曾经需要的选项可以选择,反之亦然。并且可以在产品中添加全新的选项。这会产生我最初想法的问题,因为订单项的选择列表的含义取决于订单时产品的选项。
那我该怎么办?
如果我还在订单项的选择列表中包含必需的选项,那么模型很简单。我有一个产品附带选项的快照。但是我在数据库中也有很多膨胀,因为每个订单项都会重复对所需选项的引用。这是我应该担心的事情,还是SQL Server会进行某种幕后压缩?
我是否应该追求从订单项选择列表中排除所需选项的原始想法?然后我需要保留一些有关产品变化的历史数据。这样我就可以重新创建订单时存在的产品及其选项。听起来可能但比第一个选项更复杂。我担心它需要更多的CPU周期,但如果它的旧订单不会经常打开,那就没关系。我以前从来没有这样做过,但也许不会那么难。如果这是您推荐的方法,请提供一些设计模式的指示等,以帮助我开始。
答案 0 :(得分:1)
如果您的所需选项列表将来有可能发生变化,我会选择第一个选项。如果您不将这些选项与数据库中的每个行项目一起存储,则必须跟踪哪些日期需要哪些选项,并单独加入它们。这将不必要地使您的连接逻辑复杂化。
至于膨胀你的数据库,我认为这不会像你想象的那么糟糕。听起来您可能已经有ProductOptions
和LineItemOptions
的连接表,它们只包含产品密钥和选项密钥。后一个表应该是唯一一个根据您的第一个设计选择最终拥有更多记录的表。因为它只包含密钥,所以它的记录不会占用更多的内存,无论如何加入它都会非常快。