代理键/序列号/ ID列的备用名称

Question

我有一个遗留表，其自然键的一部分有一个名为<table_name>_IDENTIFIER的列，看起来创建一个名为<table_name>_ID或ID的代理键会让人感到困惑所以我倾向于命名SURROGATE_KEY。我的所有其他表都使用<table_name>_ID语法。还有更好的建议吗？

Answer 1

不要将其称为SURROGATE_KEY。在任何其他情况下，这都是毫无意义的。我坚持<table_name>_ID。是的，这有点令人困惑。但是，鉴于你的既定惯例，其他任何事情都会让人感到困惑。

Answer 2

我可能会建议您使用您的标准：<table_name>_ID

最终，传统的表格不会成为驱动力，它将是IDENTIFIER列看起来很奇怪，这就是你想要的，而不是那样 - '哦，是的，我需要使用surrogate_key来做那件事而不是id ...'时刻。

Answer 3

首先，我不会在我的列中包含表名。列是一个属性，它需要它所属的实体的上下文。例如，具有“名称”而没有它所属的上下文是没有用的。您需要知道它是个人姓名或公司名称等，并且您以实体本身的名义拥有该名称。因此，我不会在列前面添加声明它的表的名称。

这会给你留下像“Id”，“Key”，“SurrogateKey”或者“SystemId”这样的选择，这些选择都同样含糊不清。至少“SurrogateKey”描述了什么是奖金。这个名称对DBA有意义，但也许不是开发人员（尽管他们应该理解这个概念）。在这些选择中，我倾向于使用“Id”并找到一种方法将<table_name>_Identifier更改为更具描述性的内容。

Answer 4

在绘制ER模型期间的数据建模世界中，Surrogate键如SURROGATE_KEY（或SURROGATE_ID）在创建外键约束时肯定会引起疼痛副作用。

即。通过dragg-n-dropping主键在大多数DM工具中链接父节点和子节点将自动在子节点中生成相同的列，生成列名称中的副本。

为避免这种情况，根据经验，命名代理代码如Table_name.Table_name_ID或Table_name._ID可能是不错的选择。

Answer 5

同意。 。 。不建议使用SURROGATE_ID。所有建议似乎都缺乏的是数据管理的核心。数据建模最佳实践：建立（并且一致地使用！）命名约定＆amp;价值域。建议：
1.如果数据库或编程协议（比如我厌恶自然主键的.NET）需要一个无意义的整数作为主键 - 一个代理键 - 然后创建一个值域名“Id”＆amp;将其定义为具有代理主键描述的数据类型整数。 2.在命名属性/列时，使用域“Id”的ONLY列将是使用指定的整数值填充的代理（主）键列。不允许其他属性/列使用域“Id”，因此从属性/列名称中可以清楚地看出存储的值的性质以及如何开始使用这些值。 谢谢你的机会！