sql-server - Identity 值硬编码的 SQL 最佳实践

Question

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

背景 - 一个大型企业应用程序，具有数百个表和 SP，所有这些都经过精心设计，使用规范化表和使用标识列的外键。

我们的客户有几名员工使用我们生产数据库的复制副本在 Crystal enterprise 中编写复杂的报告。

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

问题 - 报告设计者和财务分析师正在编写其中包含硬编码身份值的查询。像这样的事情

SELECT xxx FROM OFFICE WHERE OFFICE_ID = 6

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

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

但是，令人惊讶的是，我找不到任何文档甚至最佳实践文章来说明为什么不应该这样做。

他们认为这样做很好，因为这些值永远不会改变，而且他们是对的，在单个系统中这些值不会改变，但是在多个环境(登台/QA/Dev)中这些值可以并且是完全不同，使得他们的报告设计方法不可移植，并且只能在 1 个独立的服务器环境中运行。

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

Answer 1

在我看来，对你的报告作者来说最有力的论据是你的倒数第二句话“......这些值(value)观可以而且是绝对不同的[环境之间]”。这几乎就是我对他们回应的要点。

当然，任何问题都存在灰色地带。标识列本质上是 magic numbers 。它们对数据库的好处是...

• 小
• 顺序
• 快速搜索、加入、排序和创建

...但缺点是完全没有意义，并且实际上是随机分配的(以一种方式对表中的插入进行排序，每行得到的标识与以另一种方式排序时不同)。因此，如果您必须查找类似的特定内容，通常还包括“业务/自然/替代”键(例如，也许(完全虚构的示例)[CategoryName]其中 CatgoryName 是简短、唯一且人类可读的内容，而 [CategoryId] 是一个身份，但不是旨在查找的内容)

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

当人们直接针对数据库编写查询时，这会变得有点棘手。如果他们是数据的所有者，他们可能了解更大的数据结构，他们可以以*咳嗽“聪明”的方式利用这些结构。如果您知道键不会改变，并且您知道这些值是什么，则可能需要仅引用这些值。但同样，如果当您查询不同的服务器时它们会有所不同，则不会。

当然，另一方面是，如果您不希望他们使用身份值，则必须为他们提供替代方案。如果您的表尚未包含业务/自然/备用键，则您必须在尚不存在的地方添加一个。

此外，备用键也是整数也没有问题(也许您的办公室已经有公司范围的标识符 1、2、3 等)，但关键是，无论您在哪里运行您的代码，它都是确定性的查询。