我最近被要求改变我的应用程序设计并有一个解决方案，但它感觉很脏，我希望有其他选择，我没有想到。
我有一个DB表Activity，它有一个关联的Product表，它有几个字段，如名称，描述，价格等。
通常情况下，我会在填充各种产品的界面中放下一个下拉菜单，并在提交后将产品ID放入我的活动表中。每次我需要启动活动时，我只需加入密钥并提取相关的产品信息。
现在请求的是，如果您启动活动但有人已经更改了自输入活动以来产品的说明，那么它会显示原始描述，而不是新描述。
我能想到的主要解决方案是简单地复制活动表中的所有产品字段，并根据所选的下拉列表填写它们，但感觉它可能会变得非常混乱。既可以增加存储，也可以用于潜在的查询和额外的工作，如果将来需要新的列。这也让关系数据库毫无意义。
这个解决方案是我应该使用的解决方案，还是带有复制字段的混合解决方案，但保留报告/查询的外键？
由于
答案 0 :(得分：0)
这听起来不像描述变化;听起来好像正在创造一种新产品。如果产品数据内容需要在入口时间保留产品ID，则产品数据无法真正更改。需要添加新产品。描述的行为就像一把钥匙。
当描述发生变化并添加新产品时，需要停用旧产品。它仍然在域表中，因为“旧”产品记录与它绑定，但新活动项目无法使用它。原始或以前的产品ID可以存储在新产品的域表条目中。
Product ID Description is_Active Previous_Product_ID Add_Date
1 myOldDesc N 1/1/2017
2 NewDesc Y 1 1/1/2018
您将最终获得一系列产品变更。多年前我在一个系统上工作，以这种方式强迫关系设计。这很难合作。
活动表似乎包含历史数据。我建议对其进行非规范化。您仍然可以获得下拉列表的产品域表，可以根据关系实践进行修改。在更改时，创建审核记录以记录更改的历史记录。创建活动项目时，不存储product_id，而是存储实际的产品信息。关系模型的优点是您可以更改描述，而无需更改每个相关的活动记录。但在这种情况下，您不想更改相关记录，为什么要将其标准化呢？