使用 Synonyms 来避免创建重复表是个好主意吗？

Question

我们有 3 个完全相同数据库的副本。所有 3 个数据库都有一个Users表，并且一个用户将始终存在于所有 3 个数据库中，并且具有完全相同的设置。任何时候我们想要添加或编辑用户，我们都必须更新 3 个数据库。

Users从数据库 2 和 3 中删除表并将其替换为Synonym指向数据库 1的表是否更好？

这是我能想到的优点/缺点：

优点

• 更容易维护。可以在一个位置而不是 3 个位置更新用户
• 用户 ID 将在数据库之间匹配（很重要，因为许多附加应用程序都基于用户 ID）

缺点

• 不要认为这是标准程序，所以可能会造成混淆
• 用户必须在数据库之间具有相同的设置
• （来自下面gbn 的回答）如果数据库 1 出现故障，数据库 2 和 3 也将不可用。还存在恢复时数据不一致的潜在问题

这是我正在考虑的一个选项，用于包含数据库之间相同设置的几个不同表，而不仅仅是Users表。我在示例中使用用户，因为它很容易理解。

Answer 1

为什么你有相同用户的 3 个数据库？

如果一个数据库现在出现故障会怎样？

我问这些问题是因为用户源数据库的 Con 下降阻止使用其他两个数据库可能不像听起来那么大。

此外，如果一个数据库现在出现故障，如果在此期间其他两个 DB 中的用户被修改，您就会遇到一致性问题。我认为如果没有更多的背景，我们无法给出最好的建议。

现在我将为用户创建第四个数据库，仅在那里进行更改，并在其他数据库之间同步。通过在三个地方更改基本相同的数据，您已经进行了分布式非规范化，并且可能已经存在一致性问题。如果容错很重要，那么该方案在解决多入口问题的同时仍然提供了这一点。

我认为拥有第四个仅限用户/设置的数据库而不是使用现有数据库是一个很好的策略，因为它不太可能出现故障，因为它不与其他资源绑定或被大量使用。我现在明白你说你不能这样做，但我不清楚为什么。主数据库上的应用程序是否支持用户直接编辑，还是用户编辑是一个可以指向其他地方的完全独立的功能？

确实，有了这个“规范用户表”的想法——无论你使用同义词还是同步数据——你不能在用户数据库关闭期间修改用户，但这对我来说似乎没问题。解决问题并提出来！一个来源，一个编辑的地方，如果损坏则修复一件事。通过同步，所有其他数据库都有可以工作的临时副本，但不能进行编辑。最大限度地减少跨系统的数据重复是一个伟大而有用的目标。在三个地方输入相同的数据是一个严重的问题，所以尽你所能消除它。

为了解决您的更多评论，如果您的用户 ID 在所有应用程序中都不同，那么您应该认真考虑为您的两个新数据库计划停机时间，以使它们与主数据库同步（如果您需要想法，请提出一个单独的问题关于如何实现这一点，这很棘手，但并不是那么难）。

如果您分析您的业务需求并发现主数据库必须具有正常的用户数据，您仍将其用作规范，然后在同义词或同步之间进行选择，以解决计划外停机对所有数据库的影响。

使用同义词的另一个缺点是您将不再能够在每个数据库中对用户拥有适当的 FK。

Answer 2

我将创建一个第四个数据库来存储共享的用户信息。在指向用户数据库的每个其他数据库中创建Synonyms或。Views

最后，我将在 3 个现有数据库中创建一个扩展表（与“UserDB.Usertable”具有一对一关系的表），用于保存特定于该应用程序的用户数据。

编辑：根据下面的评论

在这种情况下，使第一个数据库充当主用户表。Synonyms每个其他数据库中都有一个扩展表。

重要提示：通过这种方法，如果您的第一个应用程序出现故障，其他两个应用程序也会随之崩溃！确保每个人都了解这个缺点。