使用 1:M 关系创建 1:1答案

【问题标题】：Using a 1:M relationship to create 1:1使用 1:M 关系创建 1:1
【发布时间】：2018-08-02 23:30:40
【问题描述】：

我最近被要求更改我的应用程序设计并提供解决方案，但感觉很脏，我希望那里有我没有想到的替代方案。

我有一个数据库表 Activity，它有一个关联的 Product 表，该表有几个字段，如名称、描述、价格等。

通常我会在我的界面中有一个包含各种产品的下拉菜单，并在提交时将产品 ID 放入我的活动表中。每次我需要启动一项活动时，我只需在密钥上进行连接并拉入相关的产品信息。

现在的要求是，如果您拉起活动，但有人更改了自从输入活动以来产品的描述，它显示原始描述，而不是新描述。

我能想到的主要解决方案是简单地复制活动表中的所有产品字段并根据选定的下拉列表填写它们，但感觉可能会变得非常混乱。既可以增加存储空间，也可以用于潜在的查询和额外工作（如果将来需要新列）。这也让人觉得关系数据库毫无意义。

这个解决方案是我应该使用的解决方案，还是具有复制字段的混合解决方案，但保留报告/查询的外键？

谢谢

【问题讨论】：

标签： database-design relational-database

【解决方案1】：

这听起来不像是描述更改；听起来好像正在创造一种新产品。如果产品数据内容需要在进入时与产品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。关系模型的优点是您可以更改描述，而无需更改每个相关的活动记录。但是在这种情况下，您不想更改相关记录，那么为什么要对其进行规范化呢？

【讨论】：

我相信我正在专注于我以后如何获得报告，例如如果一名工作人员更改了姓名，我想要那个人的所有历史记录，但你是对的，保持'要求改名的“历史”真的会是一名新员工。
@enfrost 我们是在谈论交易还是历史？对于员工姓名更改，我不会创建新记录。我会更改原始记录上的名称并创建审计跟踪以指示名称更改。但是对于像工资单这样的历史数据库项目，我会存储实际名称而不是标识符。因此，如果我的姓名在 10 月 1 日更改，我 9 月的工资单上仍会保留我的旧姓名，即使我的姓名已更改。