我正在研究SQL Server事务复制。我们正在开发三个内部应用程序，每个应用程序都有自己的数据库。我们需要允许同一用户访问不同的应用程序。
我们正在考虑将User数据库与应用程序数据库分开，这样我们就不会在三个不同的数据库中复制用户数据。我们希望User数据库成为发布者，将三个应用程序数据库作为复制过程中的订阅者。我们认为发布者数据库将push新注册的用户添加到订阅者，因此我们正在复制用户数据（插入/更新/删除）。
用户从发布者到订阅者的发布会在事务中发生吗？ transaction事务复制是否保证从发布者到订阅者的推送成功完成？
注册的最终结果将是包含用户GUID（以及其他数据点）的令牌。注册完成后创建的令牌将返回到调用应用程序，以便用户可以继续使用目标应用程序。
目标应用程序将解压缩令牌并使用用户的GUID确保用户有权访问该应用程序。因此，复制过程必须将用户的GUID推送到订阅者数据库，以便在目标应用程序解压缩令牌并检查相应应用程序数据库中是否存在用户的GUID后，用户的GUID可用。
我们正确地看着这个吗？非常感谢任何关于这种方法的指导。感谢。
答案 0 :(得分：2)
将所有3个应用程序指向同一个用户数据库并将所有3个应用程序insert / update放在同一个表中是不是更容易？
但是，假设你需要将它们分开，并回答你的问题......
事务复制有效，只是订阅者在正在发布的文章上的日志重播，而且速度很快。我们在工作中利用复制大量的ETL /仓库/报告目的，我们每天复制数千万行数据，几乎是实时的。有延迟，但只有一两秒。
鉴于手边的信息，你所描述的确听起来是可行的。一旦插入新用户，它将在提交事务后几乎立即出现在订阅者数据库中。
来自MSDN Transactional Replication：
“日志读取器代理程序在分发服务器上运行;它通常连续运行，但也可以根据您建立的计划运行。执行时，日志读取器代理程序首先读取发布事务日志（用于事务的相同数据库日志）在常规SQL Server数据库引擎操作期间跟踪和恢复）并识别任何INSERT，UPDATE和DELETE语句，或对已标记为要复制的事务中的数据所做的其他修改。接下来，代理将这些事务批量复制到分发中分发服务器上的数据库。日志读取器代理使用内部存储过程sp_replcmds从日志中获取标记为要复制的下一组命令。然后，分发数据库成为存储转发队列，从中发送更改到订阅服务器。 strong>仅将已提交的事务发送到分发数据库。“
我认为在这里提及合并（双向）复制也很重要。
您无法在事务（单向）复制中更新订户数据。这样做会破坏复制，通常必须重新初始化订阅才能修复它。合并复制是双向的，订户可以更新，并且这些更新会传播到发布者和其他订阅者。
合并复制配置起来比较复杂，而且根据我的经验难以维护，但是它可以让您灵活地让每个应用程序insert / update拥有自己的用户副本数据库，并将这些更改流向其他用户数据库。