标识值硬编码的SQL最佳实践

Question

首先，我知道这是一个相当主观的问题，但我需要一些正式的文件来帮助我教育我的客户。

背景--一个大型企业应用程序，有数百个表和SP，所有这些表和外键使用标识列巧妙地设计。

我们的客户有几个雇员使用我们生产数据库的复制副本在水晶企业中编写复杂的报告。

我们有存储我所认为的“系统”基本信息的表，例如公司内的办公地点或部门的列表、用户的标准角色集、其他对象的状态(开放/关闭等)，基本上是不经常变化的数据。

问题是，报表设计人员和金融分析师正在编写带有硬编码标识值的查询。就像这样

SELECT xxx FROM OFFICE WHERE OFFICE_ID = 6

我在这里大大简化了，但是基本上，他们在他们的过程中使用了这些硬编码的int值。

对于SQL开发人员来说，看到这一点显然会让您看到facepalm，因为不这样做只是一种内置的本能。

然而，令人惊讶的是，我没有找到任何关于为什么不应该这样做的文档或最佳实践文章。

他们认为这样做是可以的，因为这些值永远不会改变，而且他们是对的，在这个单一的系统中，这些值不会改变，但是在多个环境(阶段/质量保证/开发)中，这些值可以而且是绝对不同的，这使得它们的报告设计方法不可移植，并且只能在一个孤立的服务器环境中运行。

是否有任何SQL专家有更深入的信息/文章可以用来帮助我的客户了解为什么他们应该避免这种方法？

Answer 1

在我看来，对您的报告编写人员来说，最有力的论点是您的第二句话："...those值可以而且在不同的环境中完全不同“。这就是我对他们的回应的要点。

当然，任何问题都有灰色地带。标识列本质上是幻数。他们对数据库有好处.

• 小的
• 顺序
• 快速寻找和加入，排序和创建

...but的缺点是完全没有意义，实际上是随机分配的(对表中的插入进行排序，一种方式是每行获得不同的标识，而不是按另一种方式排序)。因此，在您必须查找类似特定内容的情况下，它的常见用途还包括一个“业务/自然/备用”键(例如，可能(一个完全虚构的示例) [CategoryName]，其中CatgoryName是短的、唯一的和人类可读的。[CategoryId]是一种身份，但不是要寻找的东西)

如果您有一个带有下拉菜单的网站，通常自然键会被放入下拉菜单的可见部分，代理/身份键在后端传递，最终用户看不到。

当有人直接针对数据库编写查询时，这会变得更加棘手。如果他们是数据的所有者，他们可能知道更大的数据结构的事情，他们可以利用它的“聪明”的方式。如果您知道键不会改变，并且知道这些值是什么，那么可能会有一个引用这些值的例子。但是，当您查询不同的服务器时，如果它们将是不同的，则不会。

当然，另一方面是，如果您不希望他们使用标识值，您将不得不给他们一个替代。如果您的表还没有包含一个业务/自然/备用键，那么您将不得不在不存在的地方添加一个。

另外，作为整数的备用键也没有什么问题(可能您已经为您的办公室提供了1、2、3等的全公司标识符)，但问题是，无论您在哪里运行查询，它都是确定性的。