我应该怎样命名一个将两个表映射在一起的表？
假设我有两个表格：
Table: Color Columns: Id, ColorName, ColorCode Table: Shape Columns: Id, ShapeName, VertexList 我应该怎样称呼映射颜色的表格？
Table: ??? Columns: ColorId, ShapeId
计算机科学只有两件难事：caching失效和命名事物
– 菲尔·卡尔顿
作为一个表示many-to-many关系的表格的好名字，使得这种关系更容易阅读和理解。 有时候找一个好名字并不是一件容易的事情，但通常花一些时间思考是值得的。
一个例子： Reader和Newspaper 。
Newspaper有很多Readers ， Reader有很多Newspapers
您可以调用关系NewspaperReader但像Subscription这样的名称可能会更好地expression关于该表的内容。
如果您想要将表格映射到对象，名称Subscription也更具惯用。
命名many-to-many表的约定是关系中涉及的两个表的名称的连接。 ColourShape在你的情况下是一个合理的默认值。 这就是说，我认为尼克D 提出了两个伟大的build议： Style和Texture 。
如何ColorShapeMap或样式或纹理 。
只要有信息，就可以随意命名表格：
COLOR_SHAPE_XREF
从模型的angular度来看，这个表被称为连接/相关/交叉引用表。 我保留了最后使用_XREF的习惯，使关系变得明显。
有趣的是，答案的一半给出了实现多对多关系的表的一个通用术语，而另一半答案则为这个特定的表提供了一个名称。
我通常把这些表格交叉表称为
在命名规则方面，大多数人给出的名称是多对多关系中两个表的混合。 所以在这种情况下，“ ColorShape ”或“ ShapeColor 。 但是我觉得这看起来很人性化和尴尬。
Joe Celko在他的“SQL编程风格”一书中build议用一些自然语言的方式来命名这些表。 例如，如果一个Shape由一个Color着色，则将该表命名为ColoredBy 。 那么你可以有一个或多或less自然的图表：
Shape <-- ColoredBy --> Color
相反，你可以说一个颜色的形状：
Color <-- Colors --> Shape
但是，这看起来像中间表是一个复数命名约定的Color相同的东西。 太混乱了。
可能最清楚使用ColoredBy命名约定。 有趣的是，使用被动语态使得命名约定更加清晰。
这是一个关联实体 ，往往是重要的本身。
例如，TRAINS和TIMES之间的多对多关系产生了一个TIMETABLE。
如果没有明显的新实体（例如时间表），则约定是将两个单词一起运行，给出COLOUR_SHAPE或类似的。
映射表就是通常所说的。
ColorToShape ColorToShapeMap
我通常会听到那个叫Junction Table。 我通过join的名称命名表，所以在您的情况下，ColorShape或ShapeColor。 我认为一个Shape有一个颜色比一个Color有一个形状更有意义，所以我会selectShapeColor 。
我曾与称为联接表的 DBA一起工作。
Colour_Shape是相当典型的 – 除非关系具有明确的域特定名称。
中间表或联接表
我会将其命名为“ColorShapes”或“ColorShape”，具体取决于您的偏好
Junction table
或 Bridge Table
或者 Join Table
或地 Map Table
或 Link Table
或 Cross-Reference Table
当我们进行多对多关系时，这两个表中的键构成了联结表的复合主键。
我也听说过使用联想表这个词。
您的表的名称可能是ColorShapeAssociations这意味着每行代表该颜色和该形状之间的关联。 一行的存在意味着颜色以这种forms出现，并且形状以这种颜色出现。 具有特定颜色的所有行将是与颜色相关联的所有形状的集合，并且特定形状的行将是形状进入的所有颜色的集合。
我一直偏爱“汉堡表”这个词。 不知道为什么 – 这听起来不错。
哦，我会根据哪个更常用的表格来调用表格ShapeColor或ColorShape。
“多 – 多”表。 我会把它称为“ColourShape”，反之亦然。
很难回答这样的问题，但是我更倾向于将tosh的想法命名为实际领域的东西，而不是对基础关系进行一般的描述。
很多时候，这种types的表格将会演化为更丰富的领域模型，并且会在链接的外键之上，超越其他属性。
例如，如果你需要存储除了颜色之外的纹理呢？ 展开SHAPE_COLOR表来保持其纹理似乎有点时髦。
另一方面，根据您今天的需求作出明智的决定，并在稍后引入其他需求时准备重构，也有一些东西需要说明。
所有这一切，如果我认识到后面会引入更多的表面性质的话，我会称之为SURFACE。 如果没有，我不会有任何问题称为SHAPE_COLOR或类似的东西，并转移到更紧迫的devise问题。
也许只是ColoredShape ？
我不确定我是否有问题。 这是关于这个特定的情况，还是你在寻找一般的指导方针？
一般来说，大多数数据库对索引，主键等都有某种命名约定。 在PostgreSQL中，已经提出了以下命名：
- 主键：tablename_columnname_ pkey
- 唯一约束：tablename_columnname_key
- 独占约束：tablename_columnname_excl
- 其他用途的索引：tablename_columnname_ idx
- 外键：tablename_columnname_fkey
- 序列：tablename_columnname_seq
- 触发器：tablename_actionname_after | before_ trig
你的桌子是我的一个链接表。 为了保持上面的命名，我会select以下内容：
- 链表：tablename1_tablename2_ lnk
在表对象列表中，链接表将在tablename1之后。 这可能在视觉上更具吸引力。 但是，您也可以select一个名称来描述链接的目的，就像其他人所build议的一样。 这可能有助于保持id列的名称短（如果您的链接必须有其自己的命名id并在其他表中引用）。
- 或者赞成table：intentionename_ lnk
我build议使用实体名称的组合，并将其置于复数forms。 因此，表格的名称将表示“多对多”的连接。
在你的情况下：
颜色+形状=颜色形状
我会用正在join的表格的确切名称来命名它= ColorShape。
对于开发者艺术相关的暗示，
ColorShape
将是一个通常的命名约定。 在ER图中，这将是一个关系。
将其称为交叉引用表。
XREF_COLOR_SHAPE ( XCS_ID INTEGER C_ID INTEGER S_ID INTEGER )
我会根据其含义使用r_shape_colors或r_shape_color 。
在这种情况下，会replace为xref_ 。
我的投票是一个最好的描述表的名字。 在这种情况下，它可能是ShapeColor但在许多情况下，不同于串联的名称更好。 我喜欢可读性，对于我来说 ，这意味着没有后缀，没有下划线和前缀。
我会亲自去Colour_Shape，带着下划线：只是因为我看到这个惯例出现了很多。 [但同意这里的其他post，可能有更多的“诗意”的方式）。
请记住，外键也应该build立在这个连接表上，它将引用颜色和形状表，这也有助于识别关系。
一个我看到很多join表格的约定，我个人比较喜欢的是'Colour_v_Shape'，我听过的人通俗地称之为'与表格'。
一眼就可以清楚地看到，这个表格代表了多对多的关系，当你尝试连接两个可能形成一个复合词的单词时，有助于避免（虽然罕见）混淆的情况，例如“Butter”和“牛奶”可能会变成“奶油牛奶”，但如果你还需要代表一个叫做“酪乳”的实体呢？
这样做，你会有'Butter_v_Milk'和'酪乳' – 没有混淆。
另外，我想在原问题中有一个Foo Fighters参考。
