在我们的数据库设计早期，我们使用为每个表创建任务字段，并且几个重要字段是：
created_by
created_time
created_by_ip
updated_by
updated_time
updated_by_ip
现在，它是一个无架构设计的时代。我们更喜欢mongodb或其他一些只是编写数据库。
我的问题是：
将日志保存在单独的数据库中是一种好习惯吗？
我们是否需要为每个mysql表创建单独的日志表，考虑到mongodb，或者是否可以使用单个mongodb审计表 所有mysql表？
查询mongodb的结果需要考虑哪些事项？
mongodb表结构应该是什么结构？
存储日志的其他任何替代方法？
考虑如果我们想要在指定时间内（最多48小时）未经过身份验证而删除注册用户的情况。
如果所有时间日志都在mongodb中处理。我们如何从mysql中查询相同内容？
答案 0 :(得分：1)
您通常希望在真实数据旁边显示此（审计？）数据，并且绝对不会在不同的数据库引擎中，因为要支持的部分错误数量变得非常噩梦（例如某人已注册，但您未能插入审核数据 - 这可以吗？如果该帐户变成了孤儿吗？如果该应用程序中途停止会发生什么？）。
具有此分离的系统通常使用消息传递，2个不同的侦听器负责存储数据并存储审计（例如，一个在关系数据库中，另一个在事件存储中）。通过这种方式，您有更高的机会实现最终的一致性。
使用消息传递有一些选择，这里的假设是两个数据源必须同步（或尽可能接近）。请记住，我仍然认为将数据和审计存储在一起是迄今为止最简单，最明智的方法。
使用消息传递，您的应用可以在某些事件上发出消息（例如，用户创建）。然后，2个不同的听众对此消息作出反应。一个监听器将数据存储在一个数据库引擎中;另一个侦听器存储审计数据。这种方法的问题在于您可能需要确保对消息进行排序，这使得真的慢。
另一种（可怕的）方法是在MySQL和消息传递系统之间使用分布式（XA）事务（因为mongo不支持事务）。然后将MySQL和消息的数据一起提交，监听器可以接收审计数据并将其存储在mongo中。
我需要强调的是，上述两种方法都很糟糕，应该永远不会实施。
有更明智的方法，但可能需要不同的技术堆栈。例如，使用EventSourcing + CQRS，您可以存储事件（包含审计数据）并存储最终的读取模型，而无需审计数据。