使用自然键，或使用代理键和审计表来审计/更改日志

Question

我在这里的第一个问题，请客气！

我是一名经验不足的初级开发人员，遇到了这个问题。

我有一张需要审核的表。假设此表记录呼叫中心拨打的电话（不是，但这只是一个示例）。我称之为“CallHistory”。

我最初计划保留一个名为“Callees”的单独表，其中包含被调用者的姓名、电话号码等。该表将使用代理主键。

CallHistory 表将具有 Callee 表的外键。

我最初这样做是为了如果我更改了被叫方的电话号码，它将在整个系统中传播，而我不必在多个表中更改电话号码。

问题是，CallHistory 表的全部意义在于记录呼叫的历史记录，包括误拨呼叫（例如呼叫者拨错号码）。使用这种代理键方法会丢失历史记录。

工作中的一位高级开发人员建议在 CallHistory 表中保留呼叫者在该特定时间每次拨打电话的电话号码副本，以保存历史记录。

我正在考虑为同一目的保留一个审核/更改日志表。

我的方法是否足以满足这个目的，还是我完全偏离了轨道？您更喜欢哪种方法？

干杯， 安德鲁

Answer 1

我认为你被这里关于正常形式的微妙之处误导了。问题是，与被呼叫者关联的电话号码与呼叫者拨打的号码信息不同。在一般情况下，它们可能具有相同的值，但这是另一个问题。

所以在我看来，CallHistory 应该同时包含拨号号码和对被调用者表的引用。

Answer 2

我同意瑞克的观点。是的，冗余数据非常、非常糟糕、邪恶、有臭味，而且在其他方​​面是不可取的。但是仅仅因为两个字段被称为“电话号码”并不能使它们成为同一件事。 “客户当前的电话号码”和“我们上次与他通话时客户的电话号码”不一定完全一样。

我目前正在使用一个保存销售和商品信息的数据库。项目记录包括描述、库存编号和价格等信息。我们的销售记录还包括描述、库存编号和价格。描述和库存编号是多余的，应该删除。这是一个糟糕的设计。但价格必须包含在这两个地方。当前价格与给定销售时的价格之间存在很大差异。那笔买卖可能是几年前的事了。从那时起，价格可能已经改变了十几次。

一般而言，在您描述的应用程序中，我只需将电话号码放入历史记录表中即可。拥有“电话号码历史”表并链接到适用的当时电话号码记录几乎没有什么好处。它可能会为每条记录节省几个字节，但会增加一堆复杂性。但是，如果有多个相关领域，情况就会发生变化。如果，比如说——我只是在这里发明一个例子来给出这个想法——你是一家健康保险公司，你的承保条款会因不同的州法律、该地区可用的医生等而有所不同，因此，当客户移动他的政策时必须重写，现在电话号码可能与许多其他数据项相关，因此所有数据项都应该放在一个表中，并且您链接到相应的记录。否则，您可能有一个新泽西电话号码，但您链接到加利福尼亚政策条款等。

Answer 3

您的问题是非常典型的设计困境。例如，如果您有标准格式的数据库，并且您有以下表格：销售、经理（销售人员）和区域（经理工作的地方）。您正在构建诸如“按地区分组的年度销售额”之类的报告，您可以在其中将销售与经理和经理与地区联系起来。但是，如果其中一位经理在这一年中调到另一个办公室，您的报告似乎会显示错误的数据，对吧？

什么是 3 个解决方案

1) 在某些情况下，开发人员和分析师会决定：好吧，我们的数据不是很正确，但现在还可以，我们希望保持正常形式并且不重复数据。该解决方案不太复杂。在这种情况下，您可以以正常形式创建 Callers 和 CallHistory 表，即电话号码将仅在 Callers 表中。

2) 要求不丢失任何历史更改。我们希望我们的报告和查询非常快（以数据库大小为代价）。在这种情况下，人们决定复制所有字段。例如，您可以创建包含电话号码、呼叫者姓名、地址等的 CallHistory 表，因为您预计将来每个字段都可以更改。当然，您也可以创建 Callee 表（可能您将需要它用于其他目的），但它可能会被 CallHistory 重新定义，也可能不会。假设您认为某些记录需要从 Callee 中删除，但希望它们在 CallHistory 中。当开发人员经常认为他们可以违反数据的参照完整性时，就是这种情况，不要从 CallHistory 表中创建任何外键。这是合理的，因为没有外键，插入会更快。

3) 方法我更喜欢，但从实现的角度来看它是最复杂的：CallHistory 表应该引用 CalleeHistory 表。 CalleeHistory 表将包含 Callee 表具有的所有文件，但它也有一个代理键，例如 CalleeID + DateModified（有时开发人员使用 ModificationVersionNumber 而不是 DateModified）。在 CallHistory 中，我们有一个引用 CalleeID + DateModified 的代理外键。在这种情况下，您有标准化的数据（即电话号码不在不同的表中重复），并且您没有丢失任何历史更改。

就我所说的而言，在实现的复杂性、数据库性能、数据库大小、数据完整性和系统的功能要求之间经常需要权衡取舍。如果您是初级开发人员，最好考虑所有可能的解决方案，但您可能应该听取高级开发人员的意见，他比 Stack Overflow 上的任何人都更了解您的系统和要求。

附言

如果您想了解其他方法，请阅读慢慢变化的维度，例如 http://en.wikipedia.org/wiki/Slowly_changing_dimension