我在试着解决一个问题，这一次，不是我造成的.
我工作的环境中有许多Web应用程序，这些应用程序由不同服务器上的不同数据库支持.
每个数据库在设计和应用方面都非常独特，但每个数据库中仍然有我想提取出来的通用数据.例如，每个数据库都有一个供应商表、一个用户表等...
我希望将这些公共数据抽象到单个数据库中，但仍然允许其他数据库连接这些表，甚至有键来强制执行约束，等等.我在MSSQL环境中.
有哪些选项可供 Select ？在我看来，我有以下 Select :
还有什么需要考虑的吗？
有很多方法可以用撞击来解决这个问题.我强烈建议根据您的业务需求 Select 解决方案1、2或3:
Transactional Replication:如果公共数据库是账户记录，并且您希望将数据的只读版本提供给单独的应用程序，那么您可以将核心表复制到每个单独的服务器，甚至可能只复制表的核心列.此方法的一个好处是，您可以根据需要复制到任意多个订户数据库.这也意味着您可以根据订阅者的需要自定义哪些表和字段可供订阅者使用.因此，如果一个应用程序需要用户表而不是供应商表，那么您只需要订阅用户表.如果另一个只需要供应商表而不需要用户表，那么您可以只订阅供应商表.另一个好处是复制保持自身同步，如果出现问题，您始终可以重新初始化订阅.
我已经使用事务复制从一个数据仓库推出了100多个表，以分离需要从多个系统访问聚合数据的下游应用程序.由于我们的数据仓库是按小时计划从镜像和日志(log)传送数据源进行更新的，因此生产应用程序在每小时20到80分钟的滑动窗口内拥有来自多个系统的数据.
Peer-to-Peer transactional replication作为发布类型可能更适合您提供的用例.如果您想逐 node 推出架构或复制更改，这将非常有用.标准事务复制在这方面有一些限制.
快照复制发布类型比事务性发布具有更多延迟，但如果延迟程度可以接受，您可能需要考虑这一点.
虽然您提到您是Microsoft SQL Serverstore ，但请记住，其他RDBMS也有类似的技术.由于您专门讨论的是MS SQL Server，请注意，事务性复制也允许您复制到Oracle数据库.因此，如果您的组织中有几个这样的解决方案，此解决方案仍然可以工作.
使用事务性复制的一个缺点是，如果您的中央服务器出现故障，您可能会开始感受到复制对象的下游副本中的数据出现延迟.如果复制的对象(项目)真的很大，并且您需要重新初始化表，那么这也可能需要很长时间.
Mirrors:如果希望在下游服务器上近乎实时地访问数据库，最多可以设置两个异步镜像.我以这种方式将数据与CRM应用程序集成.所有的阅读都来自与镜子的连接.所有写入都被推送到消息队列，然后该队列将更改应用到中央生产服务器.此方法的缺点是不能创建超过2个异步镜像.除非您也计划将镜像用于灾难恢复，否则您不会希望将同步镜像用于此目的.
Messaging Systems:如果您希望有许多需要来自单个中央数据库的独立应用程序，那么您可能需要考虑IBM Web Sphere、Microsoft BizTalk、Vitria、TIBCO等企业消息传递系统.这些应用程序是专门为解决此问题而构建的.它们的实现和维护往往既昂贵又繁琐，但如果您有全球分布的系统或数十个独立的应用程序，它们都需要在某种程度上共享数据，则它们可以向上扩展.
Linked Servers:听起来你已经想到了这个.您可以通过链接的服务器公开数据.我认为这不是一个好的解决方案.如果您真的想走这条路由，那么考虑将异步镜像从中央数据库设置到另一台服务器，然后将链接服务器连接设置到镜像.这将至少降低来自web应用程序的查询将导致中央生产数据库出现阻塞或性能问题的风险.
在IMO中，链接服务器往往是为应用程序共享数据的一种危险方法.此方法仍然将数据视为数据库中的二等公民.这会导致一些非常糟糕的编码习惯，特别是因为您的开发人员可能使用不同的连接方法使用不同的语言在不同的服务器上工作.您不知道是否有人要针对您的核心数据编写一个真正可怕的查询.如果您设置了一个标准，要求将共享数据的完整副本推送到非核心服务器，那么您就不必担心开发人员是否编写了糟糕的代码.至少从他们糟糕的代码不会 destruct 其他编写良好的系统的性能的Angular 来看是这样.
有很多资源可以解释为什么在这种情况下使用链接服务器是不好的.不详尽的原因列表包括:(A)the account used for the linked server must have DBCC SHOW STATISTICS permissions or the queries will not be able to make use of existing statistics，(B)查询提示除非作为OPENQUERY提交，否则不能使用，(C)与OPENQUERY一起使用时无法传递参数，(D)服务器没有关于链接服务器的足够统计信息，因此，创建了非常糟糕的查询计划，(E)网络连接问题可能导致失败，(F)any one of these five performance issues和(G)the dreaded SSPI context error when trying to authenticate windows active directory credentials in a double hop scenario.链接服务器对于某些特定方案可能很有用，但不建议围绕此功能构建对中央数据库的访问，尽管在技术上是可行的.
批量ETL流程:如果web应用程序可以接受高延迟，那么您可以编写SSIS (lots of good links in this StackOverflow question)个批量ETL流程，这些流程由SQL Server代理作业(job)执行，以在服务器之间移动数据.还有其他替代ETL工具，如Informatica、Pentaho等，所以请使用最适合您的工具.
如果您需要较低程度的延迟，这不是一个好的解决方案.我在同步到第三方托管CRM解决方案时使用过此解决方案，这些解决方案适用于可以容忍高延迟的字段.对于不能容忍高延迟的字段(基本帐户创建数据)，我们依赖于在帐户生成点通过Web服务调用在CRM中创建重复记录.
夜间备份和还原:如果您的数据可以承受高延迟(最多一天)和不可用时间段，那么您可以跨环境备份和还原数据库.对于需要100%正常运行时间的Web应用程序来说，这不是一个好的解决方案.其 idea 是，您进行基准备份，将其还原为单独的还原名称，然后在新数据库准备好使用时立即重命名原始数据库和新数据库.我已经在一些内部网站应用程序中看到过这样做，但我一般不推荐使用这种方法.这更适合较低的开发环境，而不是生产环境.
Log Shipping Secondaries:您可以在主服务器和任意数量的辅助服务器之间设置日志(log)传送.这类似于夜间备份和还原过程，不同之处在于您可以更频繁地更新数据库.在一个实例中，此解决方案用于通过在两个日志(log)传送接收方之间切换，向下游用户公开来self 们的一个主要核心系统的数据.还有另一台服务器指向这两个数据库，并在新数据库可用时在它们之间切换.我真的很讨厌这个解决方案，但是当我看到这个实现时，它确实满足了业务需求.