Sql 在多个数据库中使用同一个表

谈到数据库，我非常喜欢数据完整性。我的想法是：

• 直接在数据库中强制执行约束（例如：外键）比等待应用程序运行更好 崩溃，因为表中不存在该行或手动添加 此约束在应用程序的代码中无处不在

问题

我们有一些表在多个数据库中复制，并由多个应用程序使用。一个例子是

User

表

我们几乎在所有应用程序中都有用户。问题是，这些用户目前被单独对待，而至少我认为，他们应该全部集中在一起。目前，到处都是重复的信息，到处都是过时的用户信息。当一个用户在一个数据库/应用程序中更新时，它在另一个数据库/应用程序中不会更新，但它是同一个用户，因此他的信息应该到处更新

我们计划做什么

我们正在考虑创建一个参考数据库来重新组合所有这些信息。例如，关于用户的所有信息都将存储在同一个数据库中，每个应用程序都可以使用该数据库访问他们需要的关于用户的信息

问题1：这是个好主意吗？还有其他选择可以避免吗 到处都是重复/过时的数据

新问题

将所有用户信息分组到一个数据库可以解决重复/过时用户信息的问题，但这会产生一个关于数据完整性的新问题：

• 由于

  User

  表位于另一个数据库中，我们无法再在该表上创建外键约束

当然，用户表很容易通过视图访问，但您也不能对视图应用外键约束

问题2：那么，如果我想保留数据，我有什么选择 是否将完整性约束直接导入数据库

---

问题1：这是个好主意吗？是否有其他方法可以避免各地重复/过时的数据？

你面临的问题不是唯一的。应用程序被设计为在自己的范围内运行、拥有自己的数据并且是“独立的”。随着业界认识到维护独立系统的成本和数据质量的价值，他们一直在努力提高质量并减少开销。您将要进入的是拥有N层开发和通用公司特定代码的原因。例如，混淆数据层的服务或“DLL”，允许开发人员在控制公共信息时不知道数据库。这是个好主意吗；若你们的公司在成长，你们真的不能不这样做

另一种方法是确定单一权威来源，并将信息从该来源复制到所有其他来源；或者要求子系统在更改信息时向权威机构报告，如果两个位置的数据都发生了更改，则管理冲突

问题2：那么，如果我想将数据完整性约束直接保存到数据库中，我有什么选择？ 权威源的标识和应用程序之间的复制。确保子系统中的更新传播到主系统，主系统传播到子系统

仍然需要存在于各种系统中的唯一标识符，允许您管理完整性；但是在权威来源中保留所有代价高昂的“关联值”。考虑在用户数据库中需要用户和应用程序之间的关联，这将给系统添加一层安全性。并注意用户何时在系统中或不再在系统中（不仅仅是记录的存在，还有开始和结束日期。没有结束日期用户仍然可以访问该应用程序。

如果您使用的是sql server，我将研究该功能

它可以配置为双向或单向

单向-对主用户存储库的更改将在对订阅服务器的事务性更改中推出，但是订阅服务器也可以轮询并从发布服务器中提取。需要注意的是，在此设置中，无法写入用户表的本地副本，否则会导致复制失败，从而导致重新验证订阅的初始化

双向-这本质上更容易聊天，但是发布者和订阅者都可以更新

整个流程具有可选的更高级别的编排，使用专用的sql实例作为分发服务器集，以监视多个发布和订阅

---

为什么要重新发明轮子。如果您使用的是mssql enterprise，那么这是标准做法。

您的问题太广泛了。这实际上取决于您更重视什么，数据完整性还是数据集中。我们对您的业务一无所知。您是重审计还是不关心数据库中的更改……如果数据完整性很重要，例如ep分离用户并创建同步作业，以使它们在每个数据库中保持新鲜。这超出了问题的范围，但听起来更像是您应该有一个数据库，在某些情况下，不同的应用程序有自己的模式（如dbo），并且在协调应用程序团队之间的开发工作方面做得更多。@T.S.我知道这个问题很广泛，但我不想问一个太具体的问题，也不想错过一个更好的解决实际问题的方法，即数据完整性和集中化。最重要的一点是数据集中化。您可以为用户和标量属性。CentralDB.dbo.CentralUser.CentralUserSurrogateKey。您可以在此处添加标量数据，如LastName、FirstName。然后在每个数据库中都有一个MyApplicationDB.dbo.User.UserProgateKey