数百个别名/同义词与数据库表的完全限定名称答案

【问题标题】：Hundreds of aliases/synonyms vs database tables' fully qualified names数百个别名/同义词与数据库表的完全限定名称
【发布时间】：2011-05-15 11:12:22
【问题描述】：

鉴于多个架构中的数百个数据库表，在创建存储过程和视图时，您会建议使用别名/同义词还是完全限定名称？给定几个这样的schema.table，

Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities

我预计使用限定名称会稍微提高性能，但如果必须将诸如 Orders.Customers 之类的表移动到 Sales.Customers，我要么必须更改引用 Orders.Customers 的现有视图/过程，要么使用提前预期会采取此类行动的同义词。我看到了使用同义词将代码移动到测试中的价值，但同时我也可以创建我的生产环境的副本来测试/开发而不需要同义词。

SQL Server Books Online 建议始终使用完全限定名称。有朋友建议为数百个表中的每一个创建一个同义词，并且只使用同义词。虽然我更喜欢使用完全限定名称（更具可读性和不言自明的代码，知道什么被引用的对象属于什么模式，以及键入 schema.table 的习惯），但您观察到了哪些显着的性能、操作或可读性（缺点）优势使用同义词与完全限定的表名？

【问题讨论】：

取决于代码在环境中迁移的方式可能会影响使用完全限定名称 - 硬编码模式名称中包含“DEV”，然后将它们移动到“PRD”要求“搜索/替换” “噩梦。

标签： sql sql-server database oracle db2

【解决方案1】：

如果您预计表格真的会四处移动，请注意安全，使用完全限定名称。

【讨论】：

如果他将表移动到另一个模式，他是否不必更新一堆代码？
@Chris。是的。这个想法是，更改代码的模式应该是行人。看我的回答。

【解决方案2】：

我总是在查询中使用别名，一个主要原因是查询变得更容易阅读。一遍又一遍地重复完整的表名只会使代码混乱。

大多数情况下，表名是多余的，仅从它们来自的字段名称就可以看出。但是，您应该始终指定从哪个表中获取字段，这使得查询更易于维护，并且对数据库中的更改变得不那么敏感。

一个查询通常只使用几个表，并且由于它们是相关的，因此很容易跟踪所使用的表。如果不是，则只需确定别名含义的另一个步骤，并且该信息可在查询中直接获得。

如果您需要将表移动到不同的数据库，别名也很有帮助。由于在查询中只指定了一次完整的表名，因此更容易更改。

如果指定同一字段的不同方式在性能上存在任何差异，那将只是在解析查询的过程中，所以这将是最小的。当查询运行时，根本没有性能差异。

【讨论】：

【解决方案3】：

这是一种“视情况而定”的情况。

就个人而言，在表分布在多个模式中的应用程序中，我不希望在代码中的任何位置硬编码模式名称；为此，我将为每个具有代码的架构创建 private 同义词。

这样，如果一个表从一个模式移动到另一个模式，或者（更糟糕的是）模式被重命名），我只需要更新指向它的同义词，而不是遍历所有代码和视图。

另一方面，在某些情况下，我更喜欢编写显式引用架构的代码 - 它是用于数据迁移项目的代码，它必须引用多个架构中的同一个表，并且我们“锁定”了" 模式名称，以便它可以在 DEV/TEST/etc 中工作，而不需要大量同义词。

【讨论】：

【解决方案4】：

代码（SQL 或存储过程）应保留在数据库之外的源代码管理系统中。如果不能准确搜索替换，问题就比较严重了，确实应该先解决。

在表格数量很大的情况下，您确实需要使用前缀。不是 Sales.Customer，而是 REF_Customer。

点表示它位于单独的数据库（MS 和 Sybase）或模式（DB2 和 Oracle）中。那是一个单独的恢复单元，因此它们是单独维护的，每次跨越边界时服务器都必须切换上下文。因此，您需要牢记这一点来正确收集表，并使用一些数据库/模式，而不是很多。例如。将不经常更新的引用表分开，并且通常从其他数据库/模式中引用。

始终在 SQL 代码中使用完全限定名称。不是作为列名的前缀，而是在每个 WHERE 和 FROM 子句中。在将数据库/模式或环境、DEV 移动到 UAT 或 PROD 时，这将有很大帮助。

【讨论】：

【解决方案5】：

我的两分钱...

就我个人而言，我工作过的公司都使用完全限定的对象名称，即使在引用同一架构中的对象时也是如此。在我们确实将表移动到另一个架构的极少数情况下，我们通常在旧位置设置一个视图（不是同义词）以实现向后兼容性，主要是因为过去我们被重新验证问题所困扰。

性能方面，至少在 Oracle 中，有报告称同义词的性能略有下降，因为数据库必须首先解析同义词的名称，然后解析目标对象的名称（表/视图/包/等.)。公共同义词的性能影响稍大（是非公共同义词的 2 倍）。但是，这有些争议。请参阅this Ask Tom article 了解更多信息。但是，除非您将数据库推到极限，否则我不会担心。

【讨论】：

【解决方案6】：

任何问题的答案总是不止一个。这就是为什么“视情况而定”始终是正确答案的原因。我发现当你忠于意图并最终设计你时，你就会领先。

架构是为命名空间隔离而设计的。例如，在设计 SaaS 系统时，可以非常有效地使用模式来分离多个租户的关注点。模式还可用于将测试与生产或一个应用程序数据与另一个分开。它不仅适用于表，还适用于存储过程和所有其他数据库对象。

DB2 提供了一个称为 CURRENT SCHEMA 的特殊寄存器，它允许您对不合格的对象名称进行编码，但只需像这样设置 CURRENT SCHEMA 特殊寄存器即可切换到正确的模式：

SET CURRENT SCHEMA =  'Production'

在我看来，这比使用同义词要好得多。

【讨论】：