假设我有两张桌子：
Table: Color
Columns: Id, ColorName, ColorCode
Table: Shape
Columns: Id, ShapeName, VertexList
我该怎样称呼将颜色映射到形状的表格？
Table: ???
Columns: ColorId, ShapeId
答案 0 :(得分：158)
只有两件难事 计算机科学：缓存失效 并命名事物
- Phil Karlton
为表示many-to-many关系的表提供一个好名称可以使关系更易于阅读和理解。有时找一个好名字并不是微不足道的，但通常值得花一些时间思考。
示例：Reader和Newspaper。
Newspaper有很多Readers而Reader有很多Newspapers
你可以调用NewspaperReader这个关系，但像Subscription这样的名字可能会更好地传达这个表格的内容。
如果您希望稍后将表格映射到对象，则名称Subscription也会更加惯用。
命名many-to-many表的约定是关系中涉及的两个表的名称的串联。在您的情况下，ColourShape将是明智的默认值。也就是说，我认为Nick D came up with有两个很好的建议：Style和Texture。
答案 1 :(得分：32)
ColorShapeMap 或样式或纹理。
答案 2 :(得分：19)
有趣的是，有一半的答案为任何实现多对多关系的表提供了一个通用术语，而另一半的答案提供了这个特定表的名称。
我通常称这些表为交叉表。
就命名约定而言，大多数人给出的名称是多对多关系中两个表的混合。所以在这种情况下，“ColorShape”或“ShapeColor”。但我发现这看起来很人性和尴尬。
Joe Celko在他的书“SQL Programming Style”中建议以某种自然语言的方式命名这些表。例如，如果Shape由Color着色，则将表命名为ColoredBy。那么你可以有一个或多或少自然读取的图表：
Shape <-- ColoredBy --> Color
相反，您可以说颜色为颜色：
Color <-- Colors --> Shape
但看起来中间表与Color具有复数命名约定的内容相同。太混乱了。
可能最清楚使用ColoredBy命名约定。有趣的是，使用被动语态使得命名惯例更加清晰。
答案 3 :(得分：17)
将表格命名为您喜欢的名称，只要它提供信息：
COLOR_SHAPE_XREF
从模型的角度来看，该表称为连接/循环/交叉引用表。我一直习惯在最后使用_XREF来使关系变得明显。
答案 4 :(得分：6)
这是Associative Entity，并且本身通常很重要。
例如，TRAINS和TIMES之间的多对多关系会产生一个时间表。
如果没有明显的新实体（例如时间表），那么约定是将两个单词一起运行，给出COLOUR_SHAPE或类似的。
答案 5 :(得分：5)
通常称之为映射表。
ColorToShape
ColorToShapeMap
答案 6 :(得分：4)
我通常会听到这称为连接表。我根据它的连接命名表，所以在你的情况下，ColorShape或ShapeColor。我认为一个Shape有一个颜色比一个Color有一个形状更有意义，所以我会选择ShapeColor。
答案 7 :(得分：4)
或 Bridge Table
或 Join Table
或 Map Table
或 Link Table
或 Cross-Reference Table
当我们进行多对多关系时会出现这种情况，其中两个表中的键形成了联结表的复合主键。
答案 8 :(得分：4)
我与DBA合作，称之为加入表。
Colour_Shape相当典型 - 除非关系具有明确的特定于域的名称。
答案 9 :(得分：3)
我建议使用实体名称的组合并将它们复数形式。因此，表的名称将表示连接“多对多”。
在你的情况下：
Color + Shape = ColorsShapes
答案 10 :(得分：3)
中级表或加入表
我会将其命名为“ColorShapes”或“ColorShape”，具体取决于您的偏好
答案 11 :(得分：2)
我也听说过使用 Associative 这个词。
您的表的名称可能是ColorShapeAssociations，这意味着每一行代表该颜色与该形状之间的关联。行的存在意味着颜色以该形状出现，并且形状以该颜色出现。具有特定颜色的所有行将是与颜色相关联的所有形状的集合，并且特定形状的行将是形状所有颜色的集合...
答案 12 :(得分：2)
通常，大多数数据库都有索引，主键等的某种命名约定。在PostgreSQL中，建议使用以下命名：
你的桌子是我的链接表。为了与上面的命名保持一致，我会选择以下内容：
在表对象列表中，链接表将在tablename1之后。这可能在视觉上更具吸引力。但您也可以像其他人建议的那样选择一个描述链接目的的名称。这可能有助于保持id列的名称简短（如果您的链接必须具有自己的命名ID并在其他表中引用）。
答案 13 :(得分：1)
我一直偏爱“汉堡桌”这个词。不知道为什么 - 它听起来不错。
哦，我会调用表ShapeColor或ColorShape，具体取决于哪个是更常用的表。
答案 14 :(得分：1)
“很多很多”表。我称之为“ColourShape”，反之亦然。
答案 15 :(得分：1)
很难回答像这样随意的事情，但我倾向于选择tosh的想法，即在实际域中的某些内容之后命名它，而不是对底层关系的一些通用描述。
通常，这种表格将演变为域模型更丰富的内容，并且将在链接的外键之上和之外采用其他属性。
例如，如果除了颜色之外还需要存储纹理怎么办？扩展SHAPE_COLOR表以保持其纹理可能看起来有点时髦。
另一方面，根据您今天的要求做出明智的决定，并在以后引入额外要求时准备进行重构，也可以说些什么。
所有这一切，我称之为SURFACE，如果我有洞察力，以后会引入额外的表面特性。如果没有，我可以毫无问题地将其称为SHAPE_COLOR或类似的东西，并继续解决更紧迫的设计问题。
答案 16 :(得分：1)
也许只是ColoredShape？
我不确定我是否得到了这个问题。这是关于这个具体案例还是您正在寻找一般准则？
答案 17 :(得分：0)
将其称为交叉参考表。
XREF_COLOR_SHAPE
(
XCS_ID INTEGER
C_ID INTEGER
S_ID INTEGER
)
答案 18 :(得分：0)
关于开发者艺术与之相关的内容，
ColorShape
将是通常的命名约定。在ER图中，它将是一种关系。
答案 19 :(得分：0)
我会用正在连接的表的确切名称命名它= ColorShape。
答案 20 :(得分：0)
我会根据其含义使用r_shape_colors或r_shape_color
在这种情况下，r_会替换xref_。
答案 21 :(得分：0)
我的投票是用于最佳描述表格的名称。在这种情况下，它可能是ShapeColor但在许多情况下，与串联不同的名称更好。我喜欢可读性和 me ，这意味着没有后缀，没有下划线和前缀。
答案 22 :(得分：0)
我个人会用下划线去Colour_Shape：因为我已经看到这个惯例变得相当多了。 [但同意这里的其他帖子，可能有更多'诗意'的方式来做这件事。）
请记住，外键也应该建立在这个连接表上，它同时引用了Color＆amp;形状表也有助于识别关系。
答案 23 :(得分：0)
我看到很多关于加入我个人喜欢的桌子的约定是'Colour_v_Shape'，我听说民间俗称“与桌子对比”。
它使得一目了然地表明该表代表了多对多关系，并且当您尝试连接可能以其他方式形成复合词的两个单词时帮助避免这种情况（尽管很少见）令人困惑的情况，例如'Butter'和'Milk'可能会成为'ButterMilk'，但如果您还需要代表一个名为'Buttermilk'的实体呢？
这样做，你会有'Butter_v_Milk'和'Buttermilk' - 没有混淆。
另外，我想在原始问题中有一个Foo Fighters参考。