我试图解决一个问题,这一次,我没有创造。
我在一个有许多 Web 应用程序的环境中工作,这些应用程序由不同服务器上的不同数据库提供支持。
每个数据库在其设计和应用方面都相当独特,但每个数据库中仍然存在我想抽象出来的通用数据。每个数据库,例如有一个供应商表,一个用户表等......
我想将这些公共(public)数据抽象到一个数据库中,但仍然让其他数据库加入这些表,甚至有强制执行约束的键等......我在 MsSql 环境中。
有哪些选择?在我看来,我有以下选择:
还有什么需要考虑的吗?
最佳答案
有很多方法可以解决这个问题。我强烈推荐解决方案 1、2 或 3,具体取决于您的业务需求:
我使用事务复制从数据仓库推出 100 多个表,以分离需要访问来自多个系统的聚合数据的下游应用程序。由于我们的数据仓库每小时从镜像和日志传送数据源更新一次,因此生产应用程序在每小时 20 到 80 分钟的滑动窗口内拥有来自众多系统的数据。
Peer-to-Peer transactional replication作为发布类型可能更适合您提供的用例。如果您想逐个节点推出架构或复制更改,这可能非常有用。标准事务复制在这方面有一些限制。
快照复制发布类型比事务发布具有更多延迟,但如果延迟程度可以接受,您可能需要考虑它。
尽管您提到您是一家 Microsoft SQL Server 商店,但请记住其他 RDBM 也有类似的技术。由于您专门讨论 MS SQL Server,请注意事务复制也允许您复制到 Oracle 数据库。因此,如果您的组织中有一些这样的解决方案,该解决方案仍然可以工作。
使用事务复制的一个缺点是,如果您的中央服务器出现故障,您可能会开始遇到复制对象下游副本中的数据延迟。如果复制的对象(文章)非常大并且您需要重新初始化表,那么这也可能需要很长时间才能完成。
IMO,链接服务器往往是共享应用程序数据的危险方法。这种方法仍然将数据视为数据库中的二等公民。这会导致一些非常糟糕的编码习惯,特别是因为您的开发人员可能使用不同的连接方法在不同的服务器上工作。您不知道是否有人会针对您的核心数据编写真正令人讨厌的查询。如果您设置了一个标准,要求将共享数据的完整副本向下推送到非核心服务器,那么您就不必担心开发人员是否编写了错误的代码。至少从他们糟糕的代码不会危及其他编写良好的系统的性能的角度来看。
有很多资源可以解释为什么在这种情况下使用链接服务器会很糟糕。原因的非详尽列表包括: (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 .链接服务器对于某些特定场景很有用,但不建议围绕此功能构建对中央数据库的访问,尽管技术上可行,但不建议这样做。
如果您需要低延迟,这不是一个好的解决方案。我在与 3rd 方托管的 CRM 解决方案同步到可以容忍高延迟的领域时使用了这个解决方案。对于不能容忍高延迟的字段(基本帐户创建数据),我们依靠在帐户生成点通过 Web 服务调用在 CRM 中创建重复记录。
关于sql-server - 在 SQL 数据库之间共享数据,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16370604/