简化SQL Server数据库的复制

　　【IT专家网独家】要不再管理多个数据库和发布并不是件困难的事。假设您用SQL Server为您的一个数据库站点研发一个应用程式。他进展得很快，并且您意识到您能够对同一个应用程式只做少量的修改就能够用于另一个站点。这将按用户的需要很快就会完成，所以您决定复制代码和数据库并相应的做些修改。然后，其他的站点也需要应用程式，每一个都有自己的需要和需要。

　　来重复生产应用程式的最快方法是做一个应用和数据库的复本，并对他们做必要的改变。过一段时间，一个对应用的新的需求可能使您选择用SQL Server复制在您的站点和其他站点(可能到门户机器上)之间拷贝数据。对于每一个站点，您将创建不同的发布和订阅。

　　然后您的公司决定要合并站点，并且您要在同一台服务器(中央服务器)上部署多个数据库和多个发布。这些数据库和发布很类似但是并不相同。

　　很有可能您将开始发现他是很烦人且很复杂的——管理这个复制设计。太多的发布，太多的订阅，并且很可能在多个发布中有相同的订阅存在。听起来很类似?

　　您将对复制设计做同样的决定吗?您能够在SQL Server复制设计过程中按这些步骤来简化复制管理和控制。

　　复制设计目标

　　您要做一个成功的复制设计的目标应该将会减少管理力度和减少失败点。您能够通过维护较少的发布和订阅达到这个目标。但是，这会意味着改变数据库结构，这可能并不可行。

　　数据库设计

　　最好的方法是合并复制表来减少源数据库(只有一个源数据库更好)。这允许您减少发布的数量。当您合并时，通常有必要对数据表增加站点或数据库代码以便统一数据源。

　　复制设计

　　假如修改应用程式以便使用更少的数据库这个工作太复杂的话，一个更好的方法可能是复制表到一个临时的具备一起结构的中央数据库中。通过这个方法，订阅能够从中央数据库中利用较少的发布获得数据，就像下面图片中所显示的：

　　现在的架构：

　　只有很少的数据库具备相似的架构，而这些数据库由很少的几个应用程式修改。每个数据库具备他自己的发布，并被复制到多个订阅中：

　推荐的架构：

　　数据库被复制到一个具备一起结构的中央数据库中，改变被复制到使用较少发布的订阅中：

　　复制合并了数据之后，您就能够发布特定站点所属的数据片段。这允许您创建一个发布并根据这个站点或数据库代码增加一个WHERE条件。

　　复制总结

　　当复制模型由于应用的发展而变得太复杂的时候，简化复制模型是个很好的主意。否则，管理这大量的发布和订阅很可能会变成一件令人头疼的事。

　　TechTarget独家授权文章，严禁转载

　　查看本文国际来源>>

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有