Joo*_*oon 5 database timestamp web
我打算将'status','date_created','date_updated'包含在数据库中的每个表中.'status'用于软删除行.
然后,我发现很少有人也为每个表添加'user_created','user_updated'列.
如果我也添加这些列,那么每个表至少有5列.这会是太多的开销吗？
你觉得拥有这五个专栏是个好主意吗？
另外,'user_created'中的'user'是否意味着数据库用户？或应用程序用户？
根据上面的评论，建议仅向那些实际需要的表添加审计。
您通常希望审核应用程序用户 - 在许多情况下，应用程序（例如 Web 或 SOA）可能使用相同的凭据连接所有用户，因此存储数据库登录名是没有意义的。
恕我直言，date created/ last date updated/lastupdateby模式永远不会给出完整的图片，因为您只能看到谁做了最后的更改，而看不到更改了什么。如果您正在进行审核，我建议您使用审核触发器等模式进行完整的变更审核。如果您对表的插入/更新/删除是通过例如封装的，您还可以避免使用触发器Stored Procedures。确实，审计表会变得非常大，但它们通常不会被太多查询（通常只是在政治迫害中），并且可以存档，可以轻松地按日期分区（并且可以设为只读）。使用单独的审计表，您不需要DateCreatedorLastDateUpdated列，因为它可以派生。不过，您通常仍需要最后一次更改用户，因为 SQL 将无法派生应用程序用户。
如果您确实决定逻辑删除，我会避免使用“状态”作为指示逻辑删除的字段，因为您可能有对流程状态进行建模的表（例如付款状态等）。使用 或 字段bit，char例如ActiveYN或IsActive是常见于逻辑删除。
逻辑删除可能很麻烦，因为所有查询都需要过滤掉Active=N记录，并且在事务表中保留已删除的记录可能会使这些表变得比必要的大，尤其是在Many : Many / junction表上。性能也会受到影响，因为 2 状态字段不太可能具有足够的选择性以在索引中有用。在这种情况下，进行完整审核的物理删除可能更有意义。