我考虑使用DDD / TDD / NHibernate开发一个新的绿地应用程序，并使用反映域的新数据库模式，其中数据库中的更改需要与旧项目数据库进行双向同步。要求是两个项目将并行运行，一旦新项目开始增加比旧项目更多的业务价值，旧项目将被关闭。
我想到的一种方法是通过db触发器实现db同步。在新数据库中插入/更新/删除后，表的触发器将需要正确更新旧数据库。对于旧数据库中的更改，它的触发器需要更新新数据库。
实施例： 旧项目有一个表Quote，带有QuoteId和QuoteVersion列。正确的域模型是一个Quote对象，有许多QuoteVersion对象。所以新数据库将有两个表，Quote和QuoteVersion。因此，如果您在新数据库中更改Quote表，则触发器将需要使用旧数据库中的QuoteId或最新版本更新所有记录。接下来，如果您更新旧数据库中的引用记录，则再次更新新数据库中的记录，或者只有在旧数据库中更新最新版本的报告时才更新它。
因此，触发器中需要有一些逻辑。那些sql语句可能有点不重要。为了确保可维护性，需要对触发器进行全面测试（在一个数据库中保存数据，在第二个数据库中保存测试数据，针对不同情况）。
问题：您认为db同步的这个触发器是否可行（不确定如何确保一个触发器不会触发其他数据库触发器）？有人试过这个并发现它下地狱了吗？您是否更了解如何满足同步数据库的要求？
答案 0 :(得分：0)
这是一个非常重要的挑战，我真的不想使用触发器 - 你自己已经发现了许多问题，我会增加对性能和可用性的担忧，以及可怕的无限可能性循环错误 - 遗留应用程序中的触发器将记录插入到绿地应用程序中，导致触发器在绿地应用程序中触发以在旧应用程序中插入记录，导致触发器在旧应用程序中触发...
我见过的最干净的选项是基于消息传递系统。应用程序中的每个更改都会触发一条消息，该消息由接收端的收件人处理。收件人可以验证消息，并且 - 理想情况下 - 将其转发到处理该特定数据项的“正常”代码。
例如：
您的消息处理程序应该相对容易测试 - 您可以使用它们将每个应用程序与基础数据层中的疯狂隔离开来。它还允许您在绿地应用程序中处理不断发展的数据模式。
将其复制到遗留应用程序中可能会非常棘手 - 并且可能需要涉及触发器来捕获数据更新，但触发器内部的逻辑应该非常简单 - “发送新消息”。
双向同步很难！您可以花费大量时间来启动和运行，并在您的绿地项目发展过程中进行维护。如果您正在使用MS软件，那么值得查看http://msdn.microsoft.com/en-us/sync/bb736753。