查找表的更易读的命名约定是什么？

Question

我们总是命名查找表 - 例如国家、城市、地区...等 - 如下：
EntityName_LK 或 LK_EntityName（Countries_LK 或 LK_Countries）
但我想问是否有人有更好的查找表命名转换？

编辑：
我们认为使用后缀或前缀来解决类似冲突：
如果我们有User表和UserTypes（ID-Name）查找表，并且User和User之间存在多对多关系； UserTypes 使我们成为一个表，我们可以将其命名为 Types_For_User ，这可能会混淆 UserTypes 和 UserTypes 。 Types_For_User 因此，我们希望使查找表 UserTypes 与 UserTypesLK 一样，以便对所有人都显而易见

Answer 1

在决定需要“查找”绰号之前，您应该尝试理解为什么将某些表指定为“查找”而不是其他表。每个表本身应该代表一个实体。

当指定为“查找”的表的范围扩大并且不再被视为“查找”时，会发生什么情况？您要么更改表名称，这可能会很麻烦，要么保持原样，并且必须向每个人解释给定的表并不是真正的“查找”。

注释中提到的与连接表相关的常见场景。例如，假设用户可以有多个“类型”，这些“类型”在带有两个外键的联结表中表示。该表是否应该命名为User_UserTypes？对于这种情况，我首先会说我更喜欢在联结表上使用后缀 Member。所以我们会有Users、UserTypes、UserTypeMembers。其次，“类型”这个词在这种情况下是非常通用的。 UserType 真的意味着角色吗？您使用的术语可能会带来很大的不同。如果UserTypes确实是角色，那么我们的表名称就变成Users、Roles、RoleMembers，这看起来很清楚。

Answer 2

这里有两个关于是否使用前缀或后缀的问题。

1. 在排序的表列表中，您希望 LK 表在一起还是希望与 EntityName 相关的所有表一起出现

2. 在自动完成的环境中编程时，您是否可能想要键入“LK”来获取表列表或 EntityName 的开头？

我认为两者都有争议，但我会选择从 EntityName 开始。

Answer 3

每个表都可以成为查找表。
考虑一个人是发票表中的一个查找。
所以在我看来，表应该只命名为（单数）实体名称，例如人员、发票。

您真正想要的是列名称和约束的标准，例如

FK_Invoice_Person (in table invoice, link to person)
PersonID or Person_ID (column in table invoice, linking to entity Person)

在一天结束时，这完全取决于个人偏好（如果您可以指定它）或团队标准。

更新

如果您的查找仅与实体相关，例如 Invoice_Terms，它是从 4 个场景的列表中进行查找，那么您可以将其命名为 Invoice_LK_Terms，这将使其按“发票”下分组的名称显示。另一种方法是使用一个查找表来进行简单的单值查找，由它所针对的函数（表+列）分隔，例如

Lookups
Table | Column | Value

Answer 4

只有一种类型的表，我不认为有任何充分的理由将某些表称为“查找”表。使用对每个表都适用的命名约定。

Answer 5

表命名约定可以提供帮助的领域之一是环境之间的数据迁移。我们经常必须移动查找表中的数据（这限制了可能出现在其他表中的值）以及架构更改，因为这些允许的值列表发生了变化。目前，我们没有以不同的方式命名查找表，但我们正在考虑这样做，以防止迁移人员询问“哪些表又是查找表？”每次。