数据库实体关系的名称 Table，这是个好主意吗？
Name for DB Entity Relationship Table and is it a good idea?
我不是数据库设计专家，我怀疑这是一个新手问题。如果在其他论坛（或简单参考）中得到更好的回答，请告诉我。
给定一个 Table "Recordings" 和一个 table "Artists"。 table 都有适当定义的主键。在这些 table 之间有一种我们想要表达的关系。也就是说，一位艺术家可以有很多录音，也可以没有录音。录音只能有 1 位或 0 位艺术家。 （我们可能会有一些没有知名艺术家的模糊录音）。
我认为解决这个问题的方法是在 Recording Table 中有一个指向艺术家的外键。该字段可以为空（录音没有艺术家）。此外，我们应该定义级联删除，这样如果一个艺术家被删除，所有有外键引用该艺术家的录音现在都有一个 null 的外键。 [当你删除艺术家时，我真的很想留下实际的录音。我们真正的 table 不是 "artists" 和 "recordings"，没有艺术家也可以存在录音。
但是，我的同事们并不是这样设置的。 'Recordings' 中没有外键列，而是一个额外的 table 'RecordingArtist_Mapping' 两列，
录音键艺术家键
如果删除了艺术家（或录音），则此映射中的相应条目 table 也会被删除。我并不是说这是错误的，只是与我的预期不同。当一个人拥有多对多关系时，我当然见过这样的 table，但不是我上面描述的关系。
那么，我的问题是：
- 你听说过这种描述关系的方式吗？
- 这种table有名字吗？
- 这是建立关系模型的好方法，还是我解释的外键想法会更好？每个的pros/cons是多少？
我的同事指出，使用外键思想，录音中可能会有很多空值 Table，这违反了（也许只是精神上的？）关系数据库理论。我在这方面超出了我的联盟:)它是否违反了其中一种形式？哪一个？如何？ （简单参考的奖励积分 "Five Normal Forms" :)）。
感谢您的帮助和指导。
戴夫
是的，这是一个可行的设置，这称为垂直分区。
基本上，您将 artist 字段从 recording 移动到另一个 table，主键引用 recording。
好处是您不必通过对录音进行查找来检索艺术家，缺点是如果您仍然必须这样做，由于额外的连接，速度会稍微慢一些。
从规范化理论的角度来看，您在 Recording 中使用外键的解决方案是绝对正确的，它没有违反任何重要的范式（最重要的是第三范式和 Boyce-Codd 范式，以及两者均未违反）。
此外，从概念上更简单和安全的部分，从实际的角度来看它更有效，因为它通常减少了必须完成的连接数。在may看来，利大于弊。
Have you heard of this way of describing the relationship?
是的，这是多对多的关系。录音可以有多个艺术家。一位艺术家可以有多个录音。
Is there a name for this type of table?
我称他们为junction tables。
Is this a good way to model the relationship or would be be better off with the foreign key idea I explained? What are the pros/cons of each?
在多对多关系中需要联结 table。当你有一对多关系时，你会在许多 table.
中使用外键
至于第 4 级和第 5 级数据库规范化，这篇 1982 年的 A Simple Guide to Five Normal Forms in Relational Database Theory 文章解释了不同的级别。
Under fourth normal form, a record type should not contain two or more independent multi-valued facts about an entity.
Fifth normal form deals with cases where information can be reconstructed from smaller pieces of information that can be maintained with less redundancy.
我用这句话记住了前3级归一化。
I solemnly swear that the columns rely on the key, the whole key, and nothing but the key, so help me Codd.
从表面上看，这只是一个交集 table，它允许其他两个 table 之间存在多对多关系。
当您发现需要其中之一时，通常最好考虑 "what does this table mean" 和 "have I included all the relevant attributes"。
在这种情况下，table 告诉您艺术家以某种方式对录音做出了贡献，然后您可能会考虑 "what was the nature of the contribution"。
可能他们演奏了一种或多种特定乐器。可能他们是指挥。
然后你可能会考虑艺术家以外的人是否为录音做出了贡献——录音师？所以这会让你考虑 "artist" 是否是一个好的 table，因为你可能想要一个代表一般人的 table，然后你可以将他们中的任何一个与记录。也许您甚至想记录非个人的贡献——例如伦敦交响乐团。
您甚至可以拥有以多种方式做出贡献的实体——吉他手、歌手和制作人？您可能还会考虑是否应该对贡献进行排名，以便它们以正确的顺序列出（这可能是合同问题）。
这正是对书面作品的贡献通常建模的方式——这里是书籍 ONIX 元数据模式中使用的贡献者代码列表，作为一个说明性的行业示例：https://www.medra.org/stdoc/onix-codelist-17.htm
我不是数据库设计专家，我怀疑这是一个新手问题。如果在其他论坛（或简单参考）中得到更好的回答，请告诉我。
给定一个 Table "Recordings" 和一个 table "Artists"。 table 都有适当定义的主键。在这些 table 之间有一种我们想要表达的关系。也就是说，一位艺术家可以有很多录音，也可以没有录音。录音只能有 1 位或 0 位艺术家。 （我们可能会有一些没有知名艺术家的模糊录音）。
我认为解决这个问题的方法是在 Recording Table 中有一个指向艺术家的外键。该字段可以为空（录音没有艺术家）。此外，我们应该定义级联删除，这样如果一个艺术家被删除，所有有外键引用该艺术家的录音现在都有一个 null 的外键。 [当你删除艺术家时，我真的很想留下实际的录音。我们真正的 table 不是 "artists" 和 "recordings"，没有艺术家也可以存在录音。
但是，我的同事们并不是这样设置的。 'Recordings' 中没有外键列，而是一个额外的 table 'RecordingArtist_Mapping' 两列，
录音键艺术家键
如果删除了艺术家（或录音），则此映射中的相应条目 table 也会被删除。我并不是说这是错误的，只是与我的预期不同。当一个人拥有多对多关系时，我当然见过这样的 table，但不是我上面描述的关系。
那么，我的问题是：
- 你听说过这种描述关系的方式吗？
- 这种table有名字吗？
- 这是建立关系模型的好方法，还是我解释的外键想法会更好？每个的pros/cons是多少？
我的同事指出，使用外键思想，录音中可能会有很多空值 Table，这违反了（也许只是精神上的？）关系数据库理论。我在这方面超出了我的联盟:)它是否违反了其中一种形式？哪一个？如何？ （简单参考的奖励积分 "Five Normal Forms" :)）。
感谢您的帮助和指导。
戴夫
是的，这是一个可行的设置，这称为垂直分区。
基本上，您将 artist 字段从 recording 移动到另一个 table，主键引用 recording。
好处是您不必通过对录音进行查找来检索艺术家，缺点是如果您仍然必须这样做，由于额外的连接，速度会稍微慢一些。
从规范化理论的角度来看，您在 Recording 中使用外键的解决方案是绝对正确的，它没有违反任何重要的范式（最重要的是第三范式和 Boyce-Codd 范式，以及两者均未违反）。
此外，从概念上更简单和安全的部分，从实际的角度来看它更有效，因为它通常减少了必须完成的连接数。在may看来，利大于弊。
Have you heard of this way of describing the relationship?
是的，这是多对多的关系。录音可以有多个艺术家。一位艺术家可以有多个录音。
Is there a name for this type of table?
我称他们为junction tables。
Is this a good way to model the relationship or would be be better off with the foreign key idea I explained? What are the pros/cons of each?
在多对多关系中需要联结 table。当你有一对多关系时，你会在许多 table.
中使用外键至于第 4 级和第 5 级数据库规范化，这篇 1982 年的 A Simple Guide to Five Normal Forms in Relational Database Theory 文章解释了不同的级别。
Under fourth normal form, a record type should not contain two or more independent multi-valued facts about an entity.
Fifth normal form deals with cases where information can be reconstructed from smaller pieces of information that can be maintained with less redundancy.
我用这句话记住了前3级归一化。
I solemnly swear that the columns rely on the key, the whole key, and nothing but the key, so help me Codd.
从表面上看，这只是一个交集 table，它允许其他两个 table 之间存在多对多关系。
当您发现需要其中之一时，通常最好考虑 "what does this table mean" 和 "have I included all the relevant attributes"。
在这种情况下，table 告诉您艺术家以某种方式对录音做出了贡献，然后您可能会考虑 "what was the nature of the contribution"。
可能他们演奏了一种或多种特定乐器。可能他们是指挥。
然后你可能会考虑艺术家以外的人是否为录音做出了贡献——录音师？所以这会让你考虑 "artist" 是否是一个好的 table，因为你可能想要一个代表一般人的 table，然后你可以将他们中的任何一个与记录。也许您甚至想记录非个人的贡献——例如伦敦交响乐团。
您甚至可以拥有以多种方式做出贡献的实体——吉他手、歌手和制作人？您可能还会考虑是否应该对贡献进行排名，以便它们以正确的顺序列出（这可能是合同问题）。
这正是对书面作品的贡献通常建模的方式——这里是书籍 ONIX 元数据模式中使用的贡献者代码列表，作为一个说明性的行业示例：https://www.medra.org/stdoc/onix-codelist-17.htm