使用同义词避免创建重复表是一个好主意吗？

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

Users从数据库2和3中删除该表并将其替换为Synonym指向数据库1的a 是一个更好的主意吗？

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

优点

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

缺点

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

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

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

如果一个数据库现在宕机了怎么办？

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

此外，如果数据库现在宕机了，那么在此期间如果在其他两个数据库中修改了用户，您将已经遇到一致性问题。我认为如果没有更多背景信息，我们无法提供最佳建议。

现在，我将为用户创建第四个数据库，仅在此处进行更改，然后在其他数据库之间进行同步。通过在三个地方更改本质上相同的数据，您已经进行了分布式反规范化，并且可能已经存在一致性问题。如果容错能力很重要，那么该方案在解决多次输入问题时仍会给出解决方案。

我认为拥有第四个仅用户/设置的数据库而不是使用现有数据库中的一个是一个很好的策略，因为它与其他资源无关或未被大量使用，因此崩溃的可能性较小。现在，我知道您说您无法执行此操作，但是我不清楚原因。主数据库上的应用程序是否直接支持用户编辑，或者用户编辑的完全独立的功能可以指向其他地方？

的确，有了这种“规范用户表”的想法-无论您使用同义词还是同步数据-您都无法在用户数据库关闭期间修改用户，但这对我来说似乎是可以的。解决问题并提出来！一个来源，一个地方编辑，如果损坏，则要修复一件事。通过同步，所有其他数据库都具有可以使用的临时副本，但不能进行编辑。最小化跨系统的数据重复是一个伟大而有用的目标。在三个位置输入相同的数据是一个严重的问题，因此请尽一切可能消除这种情况。

要解决更多意见，如果所有应用程序中的用户标识都不相同，那么您应该认真考虑计划中的两个新数据库的停机时间，以使其与主要数据库保持同步（如果需要创意，请询问另一个问题）如何实现这一点，这很棘手，但并不难）。

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

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

缺少“骗局”

还原时，您的用户可能不存在于（同义词的）目标数据库中。说它已损坏，您必须从备份中还原。

也就是说，使用同义词将假定跨数据库引用完整性，这在现实生活中是不可能发生的。

当您尝试从中恢复时，此操作的另一个后果是用户ID不匹配。（通过在还原后添加用户）。但是，由于我提到的跨数据库引用完整性，无论如何都不应假定这。

所以，不要做...

dba.se上的一个相关答案：还原后何时使用非dbo模式与新数据库有关“跨数据库引用完整性”的决策标准

根据您的数据库平台，另一种选择是删除数据库2和3 中的表，并用数据库1中表的实例化视图替换它们。

优点

• 易于维护（数据）
• 匹配ID
• 中断不会影响其他数据库（至少在需要进行更改之前）
• 任何数据库都可用于恢复表。

缺点

• 数据仅是您的刷新计划的最新信息。
• 如果表定义更改，则可能还需要更改实例化视图。

还要注意，根据查找的频率，刷新的频率和数据更改的频率，这可能会或可能不会带来比同义词解决方案更多的负载。

更新： FrustratedWithFormsDesigner的注释本质上是不能执行实例化视图的平台的实例化视图。使用脚本，可以定期同步表。如果将一个数据库指定为主数据库，则所有脚本都可以基于该数据库进行更改。这将具有物化视图的所有优点和缺点；它只是无法利用内置功能。

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

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

编辑：基于下面的评论

在这种情况下，使First db充当Master用户表。Synonyms以及每个其他Db中的扩展表。

重要说明：使用这种方法，如果您的第一个应用程序出现故障，则其他两个应用程序将随之崩溃！确保每个人都了解此缺点。