你的复制设计实践难以控制吗 你可以通过减少你的数据库架构中的发布和订阅来简化SQL Server复制管理和控制……
要不再管理多个数据库和发布并不是件困难的事。假设你用SQL Server为你的一个数据库站点开发一个应用程序。它进展得很快，并且你意识到你可以对同一个应用程序只做少量的修改就可以用于另一个站点。这将按用户的要求很快就会完成，所以你决定复制代码和数据库并相应的做些修改。然后，其他的站点也要求应用程序，每一个都有自己的需要和要求。
来重复生产应用程序的最快方法是做一个应用和数据库的复本，并对他们做必要的改动。过一段时间，一个对应用的新的需求可能使你选择用SQL Server复制在你的站点和其他站点(可能到门户机器上)之间拷贝数据。对于每一个站点，你将创建不同的发布和订阅。
然后你的公司决定要合并站点，并且你要在同一台服务器(中央服务器)上部署多个数据库和多个发布。这些数据库和发布非常类似但是并不一样。
很有可能你将开始发现它是很烦人且很复杂的——管理这个复制设计。太多的发布，太多的订阅，并且很可能在多个发布中有相同的订阅存在。听起来很类似
你将对复制设计做同样的决定吗 你可以在SQL Server复制设计过程中按这些步骤来简化复制管理和控制。
复制设计目标
你要做一个成功的复制设计的目标应该将会减少管理力度和减少失败点。你可以通过维护较少的发布和订阅达到这个目标。但是，这会意味着改变数据库结构，这可能并不可行。
数据库设计
最好的方法是合并复制表来减少源数据库(只有一个源数据库更好)。这允许你减少发布的数量。当你合并时，通常有必要对数据表增加站点或数据库代码以便统一数据源。
复制设计
假如修改应用程序以便使用更少的数据库这个工作太复杂的话，一个更好的方法可能是复制表到一个临时的具有共同结构的中央数据库中。通过这个方法，订阅可以从中央数据库中利用较少的发布获得数据，就像下面图片中所显示的：
现在的架构：
只有很少的数据库具有相似的架构，而这些数据库由很少的几个应用程序修改。每个数据库具有它自己的发布，并被复制到多个订阅中：
推荐的架构：
数据库被复制到一个具有共同结构的中央数据库中，改动被复制到使用较少发布的订阅中：
复制合并了数据之后，你就可以发布特定站点所属的数据片段。这允许你创建一个发布并根据这个站点或数据库代码增加一个WHERE条件。
复制总结
当复制模型由于应用的发展而变得太复杂的时候，简化复制模型是个很好的主意。否则，管理这大量的发布和订阅很可能会变成一件令人头疼的事。