将两个表映射到一起的表应该命名为什么？

假设我有两张桌子:

Table: Color
Columns: Id, ColorName, ColorCode


Table: Shape
Columns: Id, ShapeName, VertexList

把颜色映射到形状的表应该叫什么？

Table: ???
Columns: ColorId, ShapeId
93583 次浏览
小开

这通常称为映射表。

ColorToShape
ColorToShapeMap
小开

中间表 或 a < strong > 联接表

我会把它命名为“颜色形状”或“颜色形状”，这取决于你的喜好

小开

我经常听到这个叫做结合表。我根据它连接的内容来命名表，因此在您的示例中，可以是 ColorShapeColor 或 ShapeColor。我认为一个形状有一个颜色比一个颜色有一个形状更有意义，所以我会用 ShapeColor。

小开

我将使用被连接的表的确切名称来命名它。

小开

根据开发者艺术的相关内容,

ColorShape

这是一个常见的变数命名原则在急诊图中它是一个关系。

小开

我还听说过使用 联想表这个术语。

表的名称可以是 ColorShapeAssociations，这意味着每一行表示该颜色和该形状之间的关联。行的存在意味着颜色以该形状出现，而形状以该颜色出现。具有特定颜色的所有行是与颜色相关联的所有形状的集合，而具有特定形状的行是进入形状的所有颜色的集合..。

小开

只要能提供信息，你可以随便给这张表起个名字:

COLOR_SHAPE_XREF

从模型的角度来看，该表称为连接/推论/交叉引用表。我一直保持着在最后使用 _XREF的习惯，以使这种关系显而易见。

小开

我一直偏爱“汉堡包桌”这个词，不知道为什么，它听起来很不错。

对了，我会根据哪个表更常用来调用 ShapeColor 表或 ColorShape 表。

小开

这是一个 联合实体，并且通常在其自身的权利方面是非常重要的。

例如，列车和时间之间的多对多关系产生了一个时间表。

如果没有明显的新实体(比如时间表) ，那么约定俗成的做法就是把这两个单词放在一起，给出 COLUR _ SHAPE 或类似的结果。

小开

ColorShapeMap或者 风格或者 质感怎么样。

小开

有趣的是，大约有一半的答案为实现多对多关系的任何表提供了一个通用术语，而另一半的答案则为这个特定的表提供了一个名称。

我一般称这些表为 十字路口表。

就命名约定而言，大多数人给出的名称是多对多关系中两个表的混合体。所以在这种情况下，“ ColorShape”或“ ShapeColor”但我觉得这看起来很做作，很尴尬。

JoeCelko 在他的书“ SQL 编程风格”中建议以某种自然语言的方式命名这些表。例如，如果“形状”是由“颜色”着色的，则将表命名为 ColoredBy。然后你就可以得到一个或多或少读起来像这样自然的图表:

Shape <-- ColoredBy --> Color

相反，你可以说颜色是形状:

Color <-- Colors --> Shape

但是看起来中间那张桌子和带有复数变数命名原则的 abc 0是一样的。太混乱了。

可能最适合使用 ABc0变数命名原则。有趣的是，被动语态使变数命名原则更加清晰。

小开

可以称之为交叉参照表。

XREF_COLOR_SHAPE
(
XCS_ID INTEGER
C_ID   INTEGER
S_ID   INTEGER
)
小开

我和 DBA 合作过，他们称之为 联合餐桌。

Color _ Shape 相当典型——除非关系具有显式的特定于域的名称。

小开

“多-多”表。我会叫它“颜色形状”或反之亦然。

小开
最佳答案

只有两件难事 计算机科学: 缓存失效 和命名事物 < br > —— Phil Karlton

为表示 many-to-many关系的表取一个好名字，可以使这种关系更容易阅读和理解。有时候，找到一个伟大的名字并不是微不足道的，但通常它值得花一些时间去思考。

例如: Reader和 Newspaper。

Newspaper有许多 Readers，Reader有许多 Newspapers

您可以将这种关系称为 NewspaperReader，但是像 Subscription这样的名称可能更好地表达表的内容。

如果以后需要将表映射到对象，那么 Subscription这个名称也更加惯用。

命名 many-to-many表的约定是将关系中涉及的两个表的名称串联起来。在您的情况下，ColourShape将是一个明智的默认值。也就是说，我认为 Nick D 想出来的有两个很好的建议: Style和 Texture。

小开

很难回答像这样武断的问题，但是我更倾向于 Tosh 的想法，即用实际领域中的某个东西来命名它，而不是用一些对底层关系的通用描述。

通常，这种类型的表会演变成领域模型中更丰富的内容，并在链接的外键之上和之外添加额外的属性。

例如，如果除了颜色之外还需要存储纹理，该怎么办？展开 SHAPE _ COLOR 表以保存其纹理似乎有点时髦。

另一方面，还有一些要说的是，要根据当前的需求做出明智的决策，并准备在以后引入额外需求时进行重构。

所有这一切说，我将称之为表面，如果我有洞察力，将有额外的表面样性质介绍后来。如果不是这样，我会毫不犹豫地把它命名为 SHAPE _ COLOR 或类似的名字，然后继续讨论更紧迫的设计问题。

小开

Junction table

OR Bridge Table

OR Join Table

OR Map Table

OR Link Table

OR Cross-Reference Table

当我们处理多对多关系时，就会使用这种方法，其中来自两个表的键形成联接表的组合主键。

小开

我会使用 r_shape_colors或者 r_shape_color，这取决于它的含义。
在这种情况下，r_将取代 xref_。

小开

我选择一个最能描述这张桌子的名字。在这种情况下，它可能是 ShapeColor，但在许多情况下，不同于连接的名称更好。我喜欢可读性，对于 我，这意味着没有后缀，没有下划线，没有前缀。

小开

我个人倾向于使用 Colour _ Shape，使用下划线: 仅仅是因为我已经看到这个约定出现了相当多的地方。[但是同意这里的其他帖子，可能有更“诗意”的方式来做这件事]。

请记住，外键也应该建立在这个连接表，这将引用颜色和形状表，这也有助于确定关系。

小开

也许只是 ColoredShape？

我不太明白你的问题，这是关于这个案子还是你在寻找一般的指导方针？

小开

一般来说，大多数数据库对索引、主键等都有一些变数命名原则。在 PostgreSQL 中，建议使用以下命名:

  • 主键: tablename _ columnname _ Pkey
  • 惟一约束: tablename _ columnname _ 钥匙
  • 独占约束: tablename _ column nname _ 不包括
  • 其他用途的索引: tablename _ column nname _ IDX
  • 外键: tablename _ columnname _ 见鬼
  • 序列: tablename _ columnname _ 继续
  • Tablename _ actionname _ after | before _ 三角函数

您的表是一个链接到我的表。为了与上面的命名保持一致，我会选择以下命名方式:

  • 链接表: tablename1 _ tablename2 _ 墨水

在表对象列表中，链接的表位于 tablename1之后。这可能在视觉上更吸引人。但是您也可以像其他人建议的那样，选择一个描述链接目的的名称。这可能有助于缩短 id 列的名称(如果链接必须有自己的名称 id 并在其他表中引用)。

  • 或喜欢的表: purposename _ 墨水
小开

我个人喜欢的一个加入表格的惯例是“ Color _ v _ Shape”，我听到人们把它俗称为“与表格对抗”。

一眼就能看出，这张表代表了多对多的关系，并有助于避免这种(尽管罕见)混乱的情况，当你试图连接两个单词，否则可能会形成一个复合词，例如“黄油”和“牛奶”可能会成为“酪乳”，但如果你也需要代表一个实体称为“酪乳”？

这样做的话，你会得到‘ Butter _ v _ Milk’和‘ ButterMilk’——毫无疑问。

另外，我认为在原来的问题中有一个喷火战斗机的参考。

小开

我建议使用实体名称的组合，并使用复数形式。因此，表的名称将表示连接“ many-to-many”。

就你而言:

颜色 + 形状 = 颜色形状


提交答案