在数据库方面，我是数据完整性的忠实粉丝。我的思维方式是：
问题
我们有一些表在多个数据库中重复并由多个应用程序使用。一个例子是User表。
我们几乎在所有应用程序中都有用户。问题是这些用户目前是分开对待的，至少我认为应该将他们全部组合在一起。目前，到处都有许多重复的地方，并且到处都有关于用户的过时信息。当用户在一个数据库/应用程序中更新时，它不会在另一个数据库/应用程序中更新，但它是同一个用户，所以他的信息应该在任何地方更新。
我们打算做什么
我们正在考虑创建一个参考数据库来重新组合所有这些信息。例如，有关用户的所有信息都将存储在同一个数据库中，每个应用程序都可以使用此数据库来访问他们所需的有关其用户的信息。
问题1：这是个好主意吗？是否有其他替代方法可以避免 遍布各地的重复/过期数据？
新问题
虽然将所有用户信息分组到单个数据库中可以解决重复/过期用户信息的问题，但这会产生关于数据完整性的新问题：
User表上创建外键约束，因为它位于另一个数据库中。 当然，用户表很容易通过视图访问，但是您无法在视图上应用外键约束...
问题2：那么，如果我想保留数据，我有哪些选择 完整性约束直接进入数据库？
答案 0 :(得分：1)
问题1：这是个好主意吗？还有其他方法可以避免在整个地方出现重复/过期的数据吗？
你面临的问题不是唯一的。应用程序已被设计为适合其年龄段在自己的范围内运行，拥有自己的数据并且是“自包含”的。随着行业意识到维护单独系统的成本以及数据质量的价值，他们努力提高质量并降低开销。您要了解的是拥有N-Tier Development和公司特定代码的原因。例如，服务或“DLL”混淆数据层，允许开发人员在对公共信息进行控制时不知道数据库。这是一个好主意吗;如果你的公司在增长，你实在是买不起。
替代方案是识别单个权威来源并将信息从其复制到所有其他来源;或者要求子系统在更改信息时向权威机构报告，如果两个地方的数据都发生了变化，则管理冲突。
问题2：那么，如果我想将数据完整性约束直接保存到数据库中，我有哪些选择？ 识别权威来源和应用程序之间的复制。确保在子系统中进行的更新传播到master和master传播到子项
仍需要各种系统中存在唯一标识符，以便您管理完整性;但要保留权威来源的所有“相关价值”代价高昂。考虑在用户数据库中要求用户和应用程序之间的关联，这将为系统添加一层安全性。并注意用户何时进入或不在系统中（不仅存在记录，而且还有开始和结束日期。没有结束日期的用户仍然可以访问该应用程序。
答案 1 :(得分：1)
如果您使用的是sql-server，我会查看transactional replication功能。
它可以配置为双向或单向。
单向 - 主用户存储库的更改将在订阅者的事务更改中被推出，但订阅者也可以从发布者进行轮询和提取。请务必注意，在此设置中，无法写入用户表的本地副本，否则将导致复制失败，从而需要重新初始化订阅。
双向 - 这本质上更为繁琐，但发布商和订阅者都可以更新。
整个过程具有可选的更高级别的业务流程，使用专用的sql实例作为分发器集来监控多个发布和订阅。
为什么重新发明轮子。如果您使用的是mssql enterprise，那么这是标准做法。