Question

经典数据库表设计将包含tableId int index(1,1) not null，这会导致自动增加int32 id字段。

然而，给这些数字赋予一些含义可能是有用的，我想知道人们对使用包含可枚举的表的Char（4）字段的想法。

具体来说，我在考虑一个用户角色表，其中包含数据;

"admn" - "Administrator"
"edit" - "Editor".

然后我可以在我的代码中引用这些“代码”。

更新
在编写代码以查看User.IsInRole（“admin”）而不是User.IsInRole（UserRoles.Admin）时更有意义，其中Admin是一个int，如果您重建数据库需要更新/同步。

Answer 1

id字段（与数据无关）称为代理键。它们各有利弊。您可以在this Wikipedia article上看到这些列表。就个人而言，我觉得人们过度使用他们并忘记（或从未学过）如何正确normalise a database structure。

Answer 2

我总是倾向于在表格中使用代理主键。也就是说，在业务领域中没有任何意义的密钥。主键只是数据库所需的管理数据......

在这种情况下使用'admn'作为主键有什么好处？

Answer 3

没有。不，不，不，不，不。

密钥不是数据。钥匙没有意义。这样，当意义改变时，键不会改变。

键没有编码含义。除非你有一个解码算法，否则编码意义甚至可能没有用。

由于在没有查找的情况下无法从“admn”到“Aministrator”，并且由于真正的意义，“管理员”就位于SEKRET ENKODED“有用”键旁边，为什么我会看到键而不是表格旁边的真实数据？

如果你想要一个缩写形式，一个类似枚举的名字，或者你有什么，那么称之为并意识到它是数据。那是完全可以接受的。 create table( id int not null primary key, abbv char(4), name varchar(64));

但它不是一个键，它不像一个整数键那样散列，它需要四个字符比较，并查找空终止符以将其与“edtr”进行比较，而不是一个减法来比较两个整数。没有合适的方法来生成下一个键：序列中的下一个是什么（'admn'，'edtr'，？）？

所以你失去了生成能力，简单的比较，可能的大小（如果你可以使用，一天，一个tinyint作为你的键），并且所有这些都是没有实际用途的任意值。

使用合成密钥。如果您确实需要缩写，请将其设为属性列。

Answer 4

如果主键永远不会改变，那么它就会更好。只要您更新了对它的所有引用，就可以更改主键，但这有点痛苦。

有时表中没有自然不变的列，在这种情况下，代理是有用的。

但是，如果你有一个自然不变的价值（比如一个永远不会被回收的员工ID或一组你永远不会想要改变的角色），那么最好使用它。

否则，你会引入复杂性来迎合极少发生的事情。

这只是我的意见，我的名字不是Codd或Date，所以不要把它当作福音。

Answer 5

我认为答案在你的帖子中。您的User.IsInRole（“admin”）示例将始终返回false，因为您具有char（4）的主键并使用“admn”作为管理员的密钥。

我会选择一个永远不会改变的代理主键，并且可以选择“功能主键”来查询在代码中使用硬编码的某些角色。

Answer 6

密钥本身应该没有任何特殊含义。条件往往会发生变化，因此如果密钥意味着更改，您可能需要更改密钥，而更改密钥不是您想要做的事情。

此外，当您可以放入密钥的信息量非常有限时，没有太多意义。

Answer 7

您正在比较自动增量与固定字符键，但在这种情况下，您不需要自动增加的ID。

有不同的路线可去。一种是使用枚举，映射到int id。它们不会自动递增，并且是表格的主键。

Answer 8

硬代码=＆gt;数据库引用总是一个坏主意！（除非您在申请开始之前设置它们等）。

除此之外：应该在数据库中完成admn =＆gt;管理员的映射吗？

并且您只能使用带有LATIN 23char字母的varchar4存储 23 ^ 4-（关键字） 条目。

Answer 9

如果您使用不相关的数字作为主键，则称为代理键，并且一类人认为这是最佳做法。

如果您使用“admn”作为主键，那么它被称为自然键，而另一类开发人员认为这是最佳实践。

他们两个都不会同意。这是一场古老的宗教战争（Surrogate Key vs Natural key）。因此，请使用您最熟悉的内容。只要知道有很多人支持你对不同意见的人的看法 - 无论你选择哪一个。