建立多到多关系的正确方法

Question

我正在为一个个人项目建模一个数据库，我有以下的疑问。以下选项在建模我的数据库方面有什么不同？

A选项

​

​

B选项

​

​

期权A和B的区别在于合同表的建模方式，在A选项中，合同的PK是由所有属性组成的，而在B选项中，合同的PK只是属性id_contract，但是合同有两个不能为null的前键。

这个设计的目标是允许用户和提供者之间的多个契约，以上可以通过A选项或B选项来实现，但是，如果我考虑到功能依赖关系，我需要Id_user、Id_Provider和一个数字序列来标识契约。问题是，如果数值序列是自动递增的，那么它就变成了一个替代键。撇开数据库设计的所有理论不谈，但如果这不是自增长的话，它就成为实体身份(Id_user、Id_Provider和数字序列)不可或缺的一部分。

我的问题是要知道选择建模A、或B、、考虑良好的数据库设计可能意味着什么。

非常感谢！

Answer 1

由于您有一个唯一的代理键id_Contract，所以没有理由在Contract的主键中包含其他字段:一个主键就足够了。选项"B“还可以让程序员更容易看到数据库设计的意图。

通常，在复合主键中不包含单独的代理键属性。复合键的一个很大的优点是不需要表的代理键。由于这两种设计都允许在用户和提供者之间签订多个合同，因此您没有避免使用代理密钥的明确选择。

Answer 2

这组索引

PRIMARY KEY(contract_id)
INDEX(user_id, provider_id, contract_id),
INDEX(provider_id, user_id, contract_id)

提供：

• AUTO_INCREMENT需要的其余部分，即contract_id作为某些索引中的第一列。
• 从用户到所有提供者的有效方法，反之亦然(一个多对多表)。

这也将起作用：

PRIMARY KEY(user_id, provider_id, contract_id),
INDEX(provider_id, user_id, contract_id)
INDEX(contract_id)

备注：

• 它没有强制执行UNIQUEness of contract_id，但是如果您以正常的方式使用AUTO_INCREMENT (从不使用显式值)，那么这不应该是一个问题。
• 它提供了从每一列开始的链接。

我不知道如何正确地画模型。在某种程度上，模式必须实现，这就成为了模式如何工作的真相来源。

InnoDB的实现方式，任何三重索引都变成3 BTrees，每个BTrees包含所有列，但排列方式不同。也就是说，SELECTs在性能上应该是三倍相同的。INSERTs将在BTree for contract_id的“末尾”插入，并在其他两个BTrees的不同位置插入。同样，在性能上没有差别。

更多关于多到多表的信息，http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table。