我在这里的第一个问题，所以很好！
我是一名经验不足的初级开发人员，在解决这个问题时遇到了麻烦。
我有一张需要审核的表格。假设此表记录呼叫中心拨打的电话（不是，但这只是一个示例）。我称之为“CallHistory”。
我最初计划保留一个名为“Callees”的单独表，其中包含被调用者的姓名、电话号码等。该表将使用代理主键。
CallHistory 表将具有 Callee 表的外键。
我最初这样做是为了如果我更改了被叫方的电话号码，它将在整个系统中传播，我不必在多个表中更改电话号码。
问题是，CallHistory 表的全部意义在于记录呼叫历史，包括误拨电话（比如呼叫者拨错号码）。使用这种代理键方法会丢失历史记录。
工作中的一位高级开发人员建议在 CallHistory 表中保留呼叫者在该特定时间每次拨打电话的电话号码副本，以保存历史记录。
我正在考虑为同样的目的保留一个审计/更改日志表。
我的方法是否足以满足这个目的，还是我完全偏离了轨道？您更喜欢哪种方法？
干杯，安德鲁
我认为你被这里关于正常形式的微妙之处误导了。问题是，与被叫方关联的电话号码与主叫方拨打的号码不是同一条信息。在一般情况下，它们可能具有相同的值，但这是另一个问题。
所以在我看来，CallHistory 应该同时具有拨号号码和对被调用者表的引用。
您的问题是非常典型的设计困境。例如，如果您有标准格式的数据库，并且您有以下表格：销售、经理（销售人员）和区域（经理工作的地方）。您正在构建诸如“按地区分组的年度销售额”之类的报告，您可以在其中将销售与经理和经理与地区联系起来。但是，如果其中一位经理将在年内调到另一个办公室，您的报告似乎会显示错误的数据，对吧？
什么是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 上的任何人都更了解您的系统和需求。
ps
如果您想了解其他方法，请阅读有关渐变维度的信息，例如http://en.wikipedia.org/wiki/Slowly_sharing_dimension
我同意里克的观点。是的，冗余数据非常、非常糟糕、邪恶、有臭味，而且在其他方面是不可取的。但是仅仅因为两个字段被称为“电话号码”并不能使它们成为同一件事。“客户当前的电话号码”和“我们上次与他通话时客户的电话号码”不一定是同一回事。
我目前正在使用一个保存销售和商品信息的数据库。项目记录包括描述、库存编号和价格等信息。我们的销售记录还包括描述、库存编号和价格。描述和库存编号是多余的，应该删除。这是一个糟糕的设计。但价格必须包含在这两个地方。当前价格与给定销售时的价格之间存在很大差异。那笔买卖可能是几年前的事了。从那时起，价格可能已经改变了十几次。
通常，在您描述的应用程序中，我只需将电话号码放在历史记录表中即可。拥有“电话号码历史”表并链接到适用的当时电话号码记录几乎没有什么好处。它可能会为每条记录节省几个字节，但会增加一堆复杂性。但是，如果有多个相关领域，情况就会发生变化。如果，比如说——我只是在这里发明一个例子来给出这个想法——你是一家健康保险公司，你的承保条款会因不同的州法律、该地区可用的医生等而有所不同，因此，当客户移动他的政策时必须重写，现在电话号码可能与许多其他数据项相关，因此所有数据项都应该放在一个表中，并且您链接到相应的记录。