sql - 在数据库中设计存档。也许有些模式？

Question

我们目前正在开发一个网络应用程序，其中一项功能是由用户创建事件。用户或管理员稍后可以删除这些事件。然而，客户端要求事件不是真正从数据库中物理删除，而只是标记为已删除。用户应该只能看到未删除的事件，但管理员也应该能够浏览已删除的事件。这就是所有真正的功能。

现在我建议我们应该再添加一个名为“status”的额外列，该列将具有两个有效值:ACTIVE 和 DELETED。这样我们就可以区分正常(事件)和删除的事件，并创建非常简单的查询(SELECT * FROM EVENTS WHERE STATUS = 'ACTIVE')。然而，我的同事不同意。他指出，不管现在事件事件和已删除事件共享相同信息(因此它们可以存储在同一个表中)这一事实在未来的需求中，例如我的更改和客户端将需要存储一些有关已删除事件的附加信息(比如删除日期，谁删除了它，他为什么这样做 - 有点评论)。他说，为了将来满足这些要求，我们必须在 EVENTS 表中添加额外的列，这些列将保存特定于已删除事件的数据，而不是事件事件的数据。他提出了一个解决方案，其中创建了与 EVENTS 表具有相同架构的附加表(如 DELETED_EVENTS)。每个删除的事件都将从 EVENTS 表中物理删除并移动到 DELETED_EVENTS 表。

我强烈反对他的想法。它不仅会使 SQL 查询更复杂、效率更低，而且这完全不利于 YAGNI。我也不同意他的看法，如果将来需求发生变化，我的想法会让我们在 EVENTS 表中创建额外的(不可为空的)列。在我的场景中，我会简单地创建新表，如 DELETED_EVENTS_DATA(它将保存那些额外的存档数据)，并在 EVENTS 表中添加引用键，以维护 EVETNS 和 DELETED_EVENTS_DATA 表之间的一对一关系。

尽管如此，两个在软件和数据库设计方面通常有着相似观点的开发人员可能对如何在数据库级别设计这些要求有着截然不同的看法，这让我感到很困惑。我认为我们可能都走错了方向，还有另一个(第三个)解决方案？还是只有一种选择？你如何设计这种需求？是否有关于如何正确执行此操作的任何模式或指南？任何帮助将不胜感激

Answer 1

不要使用状态栏。

至少你应该有一个 datedeleted 和一个 deletedby 列。仅仅知道某些内容已被删除是没有帮助的，即使客户在第一次查看已删除的事件时现在并没有要求，他们也会想知道是谁，以便找出原因。

如果事件表的大小可能会变得非常大，通常会将已删除/归档的数据完全移动到另一个表中。通常您会将这些表分配给不同的数据库文件。该文件通常位于不同的驱动器上以保持性能。我不是说一个全新的数据库，只是一个不同的数据库文件。

如果将它保存在同一个表中，则所有查询都应该有一个 where 子句 on (DateDeleted is null)。显然，如果将信息移动到不同的表，您就没有这个要求。这就是为什么我推荐这种做事方式的原因。