完全限定或同义词的表在另一个数据库，云迁移计划

Question

场景:在中，并计划在一两年内进入云端。

我正在用数据库A编写一个存储过程，我需要从数据库B访问一个表。

创建指向数据库B中的表的同义词还是完全限定包中的表是最佳实践吗？

Answer 1

如果您使用的云解决方案是SQL，那么您所能做的就会受到一定的限制，因为从数据库A运行的跨数据库查询必须将数据库B视为外部数据源。您在数据库B中引用的每个表都需要在数据库A中创建一个外部表。我不认为为每个表建立同义词将有助于您解决这些问题。

https://learn.microsoft.com/en-us/azure/azure-sql/database/elastic-query-getting-started-vertical?view=azuresql

Answer 2

有几种类型的对象使SQL Server中的调试和/或管理变得更加困难，这主要是因为它们最终被大多数开发人员忽略了。其中一个是触发器，另一个是同义词。

我之所以相信同义词是因为：

1. 同义词不常用，许多开发人员甚至不知道它们的存在。
2. 当查询的一部分时，同义词通常看起来(和函数)类似于一个常规的实体对象，当其他开发人员遇到一个查询时，这可能会让他们感到困惑。当他们试图追溯到同义词对象所在的位置时，他们可能需要一段时间才能意识到它是同义词，而不是像Table或View这样的实体对象。我想说的是，对于那些没有利用模式并将一切都保存在dbo中的开发人员来说，情况尤其如此。

反过来说，同义词在理论上是很好的，特别是对于抽象它们所定义的对象引用的用例而言。这样，如果在很多地方引用了这样的对象，并且有一天需要更改，那么您只需要更新同义词定义。这是对一个对象的更改，而不是必须修复所有依赖项中的引用。因此，同义词也可以提高数据库的可管理性。

此外，使用同义词的命名约定可能会帮助开发人员认识到，当他们第一次遇到同义词时，它是同义词，例如，用小写的s作为所有同义词的前缀。

至于是否应该在用例中使用一种，取决于您是否认为同义词的上述好属性大于潜在的不良属性。这里没有真正正确或错误的答案，这取决于你的决定。就我个人而言，我喜欢明确和充分限定我的引用，而不是使用同义词。