Question

我有一个数据库设计，它使用复合主键来确保唯一性，也是外键。

然后以相同的方式将这些表链接到其他表，以便最后复合键最多可以有4或5列。这导致了一些相当大的JOIN，所以我认为一个简单的解决方案是使用自动增量列，它不是主键的一部分，但是用作其他表的主键的一部分。

这是一些显示总体布局的伪代码：

CREATE TABLE Item (
id AUTO_INCREMENT,
...
PRIMARY KEY (id)
) ENGINE = InnoDB;

CREATE TABLE PriceCategory (
id AUTO_INCREMENT,
...
PRIMARY KEY (id)
)

CREATE TABLE ItemPriceCategory (
itemId,
priceCategoryId,
id AUTO_INCREMENT,
...
UNIQUE INDEX id,
PRIMARY KEY (eventId, priceCategoryId)
)

CREATE TABLE ClientType (
id AUTO_INCREMENT,
...
PRIMARY KEY (id)
)

CREATE TABLE Price (
itemPriceCategoryId,
clientTypeId,
id AUTO_INCREMENT,
...
UNIQUE INDEX id,
PRIMARY KEY (itemPriceCategoryId, clientTypeId)
)

table Purchase (
priceId,
userId,
amount,
PRIMARY KEY (priceId, userId)
)

表格的名称已被更改以保护无辜者;-)此外，实际布局在参考方面稍微深一些。

所以，我的问题是，从性能和数据完整性的角度来看，这是一个可行的策略吗？是否更好地拥有Purchase表中所有引用表的所有键？

提前致谢。

Answer 1

通常，对主键的建议是使用“无意义”的不可变主键和单个列。自动递增整数很好。

所以，我会改变你的设计 - 你的连接表也应该有无意义的主键。例如：

CREATE TABLE ItemPriceCategory (
itemId,
priceCategoryId,
id AUTO_INCREMENT,
...
PRIMARY KEY id,
UNIQUE INDEX  (eventId, priceCategoryId)
)

这样，price中的itemPriceCategoryId列是一个正确的外键，链接到ItemPriceCategory表的主键。

然后，您可以使用http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html外键来确保数据库的一致性。

就性能而言，从广义上讲，这种策略应该比在连接中查询复合键更快，但是对于索引良好的数据库，您可能实际上没有注意到差异......

Answer 2

我认为这里的翻译已经丢失了，但我尽力制作一个 ER 图表。

一般来说，有两种方法。第一个是传播密钥，第二个是为每个表都有一个自动增量整数作为 PK 。

第二种方法通常由使用 DB 作为对象持久性存储的ORM工具驱动，而第一种方法（使用密钥传播）更常见于手工制作的 DB < / strong>设计。

通常，具有密钥传播的模型为“随机查询”提供了更好的性能，主要是因为您可以在联接中“跳过表”。例如，在具有密钥传播的模型中，您可以将Purchase表直接加入Item表，以按ItemName报告购买情况。在其他模型中，您还必须加入Price和ItemPriceCategory表格 - 只需访问ItemID。

基本上，具有密钥传播的模型本质上是关系型的 - 而另一个是对象驱动的。 ORM工具要么更喜欢或强制使用具有单独ID的模型（第二种情况），而是为开发提供其他优势。

你的例子似乎是尝试使用这两者的某种组合 - 不一定是坏的，如果你能与原创设计师交谈会有所帮助。

使用密钥传播

每个表的独立键

MySQL - 自动增量+复合主键 - 性能＆amp;廉正

2 个答案: