链接表是否需要无意义的主键字段？

Question

我正在研究几个链接表,我开始思考(Danger Will Robinson,Danger)链接表的可能结构是什么,他们的专业人士和骗子是什么.

我想到了链接表的一些可能的限制:

传统的3柱模型

• id - 自动编号的PRIMARY
• table1fk - 外键
• table2fk - 外键

在大多数书籍中,这是一个经典,"努夫说.

索引3列模型

• id - 自动编号的PRIMARY
• table1fk - 外键 INDEX ('table1fk')
• table2fk - 外键 INDEX ('table2fk')

根据我自己的经验,您要查询的字段未在传统模型中编入索引.我发现索引外键字段确实提高了预期的性能.这不是一个重大改变,而是一个很好的优化调整.

复合键2列 ADD PRIMARY KEY ('table1fk' , 'table2fk')

• table1fk - 外键
• table2fk - 外键

有了这个,我使用复合键,以便table1中的记录只能链接到table2上的记录一次.因为密钥是复合的,所以我可以添加记录(1,1),(1,2),(2,2)而不会出现任何重复错误.

复合键2列选项的任何潜在问题？这可能会导致索引问题吗？表现受到了打击？有什么东西可以取消这个可能的选择吗？

Answer 1

我会使用复合键,没有额外的无意义键.

我不会使用在我的数据库结构上强制执行此类规则的ORM系统.

Answer 2

对于真正的链接表,它们通常不作为对象模型中的对象实体存在.因此,从未使用过代理密钥.从集合中移除项目导致从链接关系中移除项目,其中两个外键都是已知的(Person.Siblings.Remove(Sibling)或者Person.RemoveSibling(Sibling)在数据访问层处被适当地翻译为usp_Person_RemoveSibling(PersonID, SiblingID)).

正如迈克所提到的,如果它确实成为对象模型中的实际实体,那么它可能值得一个ID.然而,即使添加了诸如关系的有效开始和结束日期等时间因素以及类似的事情,它也并不总是很清楚.例如,集合可能具有在聚合级别关联的生效日期,因此关系本身可能仍然不会成为具有任何公开属性的实体.

我想补充一点,你可能需要在两个外键列上以两种方式索引表.

Answer 3

如果这是一个真正的多对多连接表,那么转储不必要的id列(除非你的ORM需要一个.在这种情况下,你必须决定你的智力是否会胜过你的实用性).

但我发现真正的连接表非常罕见.通常不久我就开始想要在该表中放入一些其他数据.因此,我几乎总是从一开始就将这些连接表建模为实体,并在那里粘贴一个id.

Answer 4

拥有单列pk可以帮助解决灾难恢复问题.因此虽然理论上你是正确的,但你只需要2个外键.实际上,当狗屎击中风扇时,您可能需要单列密钥.我从来没有遇到过被搞砸的情况,因为我有一个列标识符,但是我一直在那些被搞砸的地方,因为我没有.