例如，假设我有一张产品表。我应该存储日志信息，例如它的创建者、最后编辑者、最后更新日期……或者如果日志信息与实际应用程序无关，我应该将日志信息分隔在一个审计表中吗？
谢谢你。
问问题
212 次
8 回答
5
如果您认真考虑保留审计信息，则应将其放在单独的表中。最后更新的东西只会被覆盖，它不能替代。如果您向键添加时间戳，那么您可以将历史记录保存在同一个表中，但代价是查询更加昂贵并且应用程序逻辑更加复杂，所以我建议不要这样做。
于 2010-05-14T13:16:24.050 回答
4
我通常会在每个表中保留 LastChangeUser 和 LastChangeDate 列信息，有时还包括 CreateUser 和 CreateDate。这通常对大多数桌子都有好处。
但是，如果您需要存储更多，对于非常重要的表（通常与金钱相关），请转到另一张表。在该表 (OriginalTableName_History) 中，我通常有一个 HistoryID，它是一个自动增量、一个 HistoryDate 和一个 HistoryType（I=insert、U=update、D=delete），然后是原始表中的所有列。我通常会在主表上有一个触发器，它将每个更改（插入/更新/删除）放入历史表中。
于 2010-05-14T13:27:21.677 回答
3
您必须始终将您的操作数据库（有关产品、客户等的当前信息）与日志存储分开。根据具体情况，我还建议您创建一个“历史”数据库，并在其中存储所有遗留数据，以免过度使用操作数据库。在大型数据库上执行选择总是很慢，因此您必须以任何可能的方式减小它的大小并创建索引以提高性能。日志信息应存储在其他数据库中。我不认为“上次修改者”之类的字段是日志信息，您可以将它们放在您希望的任何表上。我还建议您在操作数据库上不要有太多外键（存储您的日志信息而不直接引用操作数据），因为它也会减慢您的数据管理速度。
希望能帮助到你。
于 2010-05-14T13:55:26.437 回答
3
简而言之，最好放在单独的桌子上。
于 2010-05-14T13:13:12.047 回答
1
如果您的应用程序只需要知道产品的当前属性是什么，那么将审计信息放在另一个表中是合适的，因为它可以简化查询并提高性能。
另一方面，如果您需要能够在特定时间点重建实体（例如，如果您的应用程序通常需要能够回答“我们在 2004 年以什么品牌销售此产品？”的问题），您永远不应该更改记录：对实体的更改是实体数据的一部分，应该在同一个表中。（参见 Martin Fowler 的文章“随时间变化的事物的模式”，在面向对象的上下文中对此进行了很好的讨论。）
于 2010-05-14T13:27:05.243 回答
1
这取决于您的应用程序以及您要保存的信息量。一些框架（例如 Ruby on Rails）可以自动更新诸如 created_by 之类的字段，因此如果您具有这种灵活性并且只需要几个字段，那么将其保存在同一个表中可能会更容易。
但是，如果您要记录详细信息，例如谁在什么时间更改了记录，那么单独的表可能会更好。这样，您甚至可以保留对记录所做的所有更改的滚动历史记录，以用于审计目的。
于 2010-05-14T13:15:38.170 回答
1
您记录的有关每个产品的元数据集是否可能会增长？如果是这样，请将其放在另一个表中，以便您可以添加项目。
如果它是一个不会增长的具体集合，那么它可能无关紧要。通过使用单独的表格，您获得了一些概念上的优雅，但您放弃了少量的效率和复杂性。
于 2010-05-14T13:16:39.480 回答
1
我会把它分开，特别是如果你想保持审计跟踪。使用您的实体登录意味着每个实体只能有一个日志记录条目。它还混合了不同的关注点——对实体的更改和实体本身是不同的概念，最好放在单独的表中。
使用组合表，删除实体将删除该实体的所有审计信息，这可能不是您想要的。
于 2010-05-14T13:14:31.580 回答