我打算将'status'，'date_created'，'date_updated'包含在数据库中的每个表中。 'status'用于软删除行。
然后，我发现很少有人也为每个表添加'user_created'，'user_updated'列。
如果我也添加这些列，那么每个表至少会有5列。 这会是太多的开销吗？
你觉得拥有这五个列是个好主意吗？
此外，'user_created'中的'user'是否意味着数据库用户？还是应用程序用户？
答案 0 :(得分：3)
我以前用过全部五个，当然。当我想通过网络应用程序跟踪谁正在创建和（最后）编辑记录时，当发生这种情况时，我会包含时间戳和登录用户（但不包括数据库用户，这不是我的系统设置方式;我们使用一个帐户进行所有数据库交互。）
同样，如果用户正在更改记录的状态，状态也会很有用。如果它从“在线”变为“离线”到“存档”，该记录可以反映出来。
但是，我不会在每张桌子上都使用这些，也不应该。有时我的表只用于存储记录的一部分（normalized），或者只是没有值，只要需要由谁创建的状态或时间。
您应该为每个表考虑的是主键字段。除非你的方法比你听起来更复杂，否则你几乎总是想要一个。有些东西不一定需要一个（例如，状态列表可以是Unique的缩写）。但是对于大多数表来说，这比一系列时间戳和状态字段更重要。
答案 1 :(得分：3)
根据上述评论，建议仅将审核添加到实际需要它的表中。
您通常希望审核应用程序用户 - 在许多情况下，应用程序（例如Web或SOA）可能使用相同的凭据连接所有用户，因此存储数据库登录是没有意义的。
恕我直言，date created / last date updated / lastupdateby模式永远不会全面展示，因为您只能看到谁做了最后一次更改而没看到更改的内容。如果您正在进行审核，我建议您使用审核trigger等模式进行完整的更改审核。如果对表的插入/更新/删除进行了封装，也可以避免使用触发器，例如：通过Stored Procedures。确实，审计表会变得非常大，但通常不会被查询太多（通常只是在寻找猎物），并且可以存档，按日期轻松划分（并且可以只读取）。使用单独的审核表，您不需要DateCreated或LastDateUpdated列，因为这可以派生。但是，您通常仍然需要最后一个更改用户，因为SQL将无法派生应用程序用户。
如果您确定了逻辑删除，我会避免使用'status'作为指示逻辑删除的字段，因为您可能有表格来确定流程状态（例如付款状态等）。使用{{1 {}}或bit字段（例如char或ActiveYN）对于逻辑删除是常见的。
逻辑删除可能很麻烦，因为所有查询都需要过滤掉IsActive条记录，并且通过在事务表中保留已删除的记录可以使这些表格大于必要，特别是在Active=N表上。性能也会受到影响，因为2状态字段不太可能具有选择性，足以在索引中起作用。在这种情况下，完整审计的物理删除可能更有意义。
答案 2 :(得分：2)
简单回答 - 只在数据库中将其放入数据库中。