Database 新绿地项目数据库和旧项目数据库之间的数据库同步

我正在考虑使用DDD/TDD/NHibernate开发一个新的greenfield应用程序，该应用程序具有一个反映域的新数据库模式，其中数据库中的更改需要以两种方式与旧项目数据库同步。要求两个项目并行运行，一旦新项目开始比旧项目增加更多的业务价值，旧项目将被关闭

我想到的一种方法是通过db触发器实现db同步。在新数据库中插入/更新/删除后，表的触发器将需要正确更新旧数据库。与旧数据库中的更改相同，其触发器需要更新新数据库

例如： 旧项目有一个表引号，列为QuoteId和QuoteVersion。正确的域模型是一个Quote对象，包含许多QuoteVersion对象。因此，新数据库将有两个表，Quote和QUOTEEVERSION。因此，如果在新数据库中更改Quote表，触发器将需要使用旧数据库中的QuoteId或最新版本更新所有记录。接下来，如果更新旧数据库中的Quote记录，则再次更新新数据库中的记录，或者仅当更新旧数据库中Quote的最新版本时，它才可能更新该记录

因此，触发器中需要有一些逻辑。这些sql语句可能是非常重要的。为了确保可维护性，需要对触发器进行彻底的测试（对于不同的情况，将数据保存在一个db中，将测试数据保存在第二个db中）

---

问题是：您认为这种db同步的触发器想法可行吗（还不确定如何确保一个触发器不会触发另一个数据库触发器）？有人试过后发现它会下地狱吗？您对如何满足同步数据库的要求有更好的想法吗？

这是一个非常重要的挑战，我不想使用触发器-您自己已经确定了许多问题，我还要补充关于性能和可用性的问题，而可怕的无限循环错误的明显可能性-传统应用程序中的触发器将记录插入绿地应用程序中，导致绿地应用程序中的触发器触发在传统应用程序中插入记录，导致传统应用程序中的触发器触发

我见过的最干净的选择是基于消息传递系统。应用程序中的每个更改都会触发一条消息，该消息由接收方处理。收件人可以验证消息，理想情况下，将其转发给处理特定数据项的“正常”代码

例如：

• 旧版应用程序创建新的“报价”记录
• 旧版应用程序发送带有新“报价”表示的消息
• 消息总线将消息转发给绿地应用程序“newQuoteMessageHandler”
• 绿地应用程序“newQuoteMessageHandler”验证数据
• 绿地“newQuoteMessageHandler”实例化“quote”域实体，并用数据填充它
• greenfield域实体处理剩余的持久性和关联的业务逻辑

您的消息处理程序应该相对容易测试——您可以使用它们将每个应用程序与底层数据层中的应用程序隔离开来。它还允许您在greenfield应用程序中处理不断变化的数据模式

将其重新安装到旧版应用程序中可能很棘手，并且可能需要使用触发器来捕获数据更新，但触发器内部的逻辑应该非常简单——“发送新消息”

---

双向同步很难！您可以期望花费大量的时间来启动和运行它，并随着绿地项目的发展进行维护。如果您正在使用MS软件，那么值得一看

我可以看到一个问题与信息。数据库的更新不会在同一事务中发生，在处理消息之前，数据可能会不同步。如果消息处理程序失败，数据将保持不同步。事实上-但是如果要将分布式事务和实时同步添加到混合中，我认为，如果不在同步上投入比项目本身更多的时间，您的项目就不可能成功，尤其是在您有性能和可伸缩性需求的情况下。实际上，消息传递解决方案增加（最多）秒而不是分钟的延迟。“如果处理程序失败”的担忧同样适用于触发器，但通过使用消息传递方案，您可以做出更明智的决策——例如，您的错误处理代码可以向帮助台发送电子邮件。“如果处理程序失败”的担忧同样适用于触发器。不是真的，如果触发器失败，整个事务就会失败。要么全部，要么一无所有。这些失败基本上会指出未涵盖的领域（好东西）。现在我正在研究CLR触发器，运行C代码来执行插入/更新/删除逻辑。到目前为止，我能够通过在c#中设置另一个触发器实际运行的标志来解决“触发器”问题。虽然我完全同意，但同步比项目本身更昂贵会带来巨大的风险。当天我们通过sql server 2008“更改跟踪”（change tracking））实现了一些同步原型，并决定不继续使用这种同步想法，因为它太贵了。