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

Question

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

Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities

我希望使用限定名称可以稍微提高性能，但是如果必须将诸如 Orders.Customers 之类的表移动到 Sales.Customers，我将不得不更改引用 Orders.Customers 的现有 View /过程或使用提前的同义词，预计会有这样的举动。我看到使用同义词将代码转移到测试中的值(value)，但同时我也可以创建生产环境的副本来测试/开发，而不需要同义词。

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

Answer 1

代码(SQL 或存储过程)应该保留在数据库之外的源代码管理系统中。如果您不能准确地搜索和替换，您就会遇到严重的问题，所以确实应该首先解决这个问题。

如果表格数量很大，您确实需要使用前缀。不是 Sales.Customer，而是 REF_Customer。

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

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