这是我昨天提出的关于存储历史数据（Storing data in a side table that may change in its main table）的问题的更深入的跟进，我正试图缩小我的问题范围。
如果您有一个表在应用程序级别表示数据对象的表，并且需要该表用于历史目的，那么将其设置为无法删除信息的位置被认为是不好的做法。基本上我有一个表格表示工人的安全要求，我想这样做是为了永远不会删除或更改这些要求。因此，如果需要进行更改，则会创建新记录。
这不是个好主意吗？处理这类数据的最佳做法是什么？我有一个包含历史安全培训数据的表，它指向带有需求数据的表（以及一些其他关键表），因此我不能让需求被更改，或者历史表将指向错误的信息。 / p>
答案 0 :(得分：2)
这不是个好主意吗？
您的情景对我来说听起来非常有效。如果您有需要的历史数据，那么有多种方法可以满足这一要求。
选项1 ：
将所有历史数据和当前数据存储在一个表中（确保存储创建日期，以便了解旧的和新的）。当您需要为某人检索最新记录时，只需将其基于表中存在的最新日期。
选项2 ：
将所有历史数据存储在单独的表中，并将当前数据保存在另一个表中。如果您正在使用数百万条记录，这可能会有所帮助，因此您不会降低构建在其上的任何应用程序的性能。无论是在创建新记录时，还是通过一些夜间工作，您都可以将旧数据移动到另一个表中，以保持当前表的轻量级。
答案 1 :(得分：1)
这是另一种选择，不一定是“更好”，但需要记住......
您可以拥有单独的“活动”和“历史”表，然后创建触发器，以便每当修改或删除活动表中的行时，旧行值将复制到历史表中，连同时间戳。
这样，应用程序可以以自然的方式使用活动表，而在历史表中自动生成准确的更改历史记录。由于这适用于DBMS级别，因此您可以更好地抵御应用程序错误。
当然，如果您需要维护整个对象图的历史记录（即通过FOREIGN KEY链接的几个表），事情会变得更加混乱。可能最简单的选择是简单地放弃历史表的参照完整性，并将其保留为活动表。
如果这还不足以满足您项目的需求，那么您必须以某种方式代表整个图表在变更时的“快照”。一种方法是将连接视为版本化对象。或者，您可以只复制端点对象的每个版本的所有连接。这两种情况都会使你的逻辑显着复杂化。