问MySQL -我应该在每个子表上使用多列主键吗？

EN

这些数据是标准化的。

TABLE { FIELDS }
-----------------------------------------------------------------------
building { id, data } 
floor { id, building_id, data }
room {id, floor_id, data }
bed {id, room_id, data }

这张桌子不错(好主意)

TABLE { FIELDS }
-----------------------------------------------------------------------
building { id, data } 
floor { id, building_id, data }
room {id, building_id, floor_id, data }
bed {id, building_id, floor_id, room_id, data }

在第一个(好的)表中，

1. 没有不必要的重复数据。在第一个表中插入
2. 要快得多。
3. --第一个表将更容易地放入内存中，从而加快查询速度。
4. InnoDB是在考虑模型A的情况下进行优化的，而不是使用B模型进行优化的。
5. (坏的)表有重复的数据，如果不同步，则会造成混乱。DB A很难脱离同步，因为数据只列出一次。
6. ，如果我想把A型和B型的data从大楼、楼层、房间和床上合并起来，你在这里怎么节省时间？select
7. InnoDB将索引数据存储在它自己的文件中，如果您只为索引，则表本身将不会被访问。那么你为什么要复制索引呢？无论如何，MySQL都不需要读取主表。
8. InnoDB将PK 存储在每个次要索引中，使用一个复合的和长的PK，您正在减慢使用索引和平衡文件大小的每一个选择；无论如何，都不会得到任何好处。
9. 你有严重的速度问题吗？如果不是，您是否正在对表进行反错操作？
10. 甚至都不考虑使用受这些问题影响较小的MyISAM，它不是针对多连接数据库进行优化的，也不支持引用完整性或事务，而且使用复合键对此floor_id的匹配很差--您只能使用键的最右边的部分，也就是说，除了使用id+building_id+floor_id之外，不能在表bed中使用floor_id，这意味着您可能必须使用比模型A中需要的更多的密钥空间，或者您需要添加一个额外的索引(这将拖曳PK的完整副本)。

In

我看到了绝对零的好处和许多缺点，在模式B，永远不要使用它！

我认为你的第二名不太可能是比尔·卡温的意思。通常，"id“意味着自动数字序列。我觉得他更有可能是这么说的。组成主键的列在星号之间。

TABLE    { COLUMNS }
-----------------------------------------------------------------------
building { *building_id*, other columns } 
floor    { *building_id, floor_num*, other columns }
room     { *building_id, floor_num, room_num*, other columns }
bed      { *building_id, floor_num, room_num, bed_num* (?), other columns }

不过，我不知道你还有什么“床”专栏。双胞胎，满的，王后，国王？这可能是有道理的。如果是这样，那么这张桌子

bed      { *building_id, floor_num, room_num, bed_num*, bed_size }

远非“非正常化”。事实上，它是在5NF中。

如果您测试这两个模式的性能，您可能会发现这个模式在大多数情况下都围绕您的#1运行。在我运行的一批查询中，速度大约快了30倍。

第一个表结构是规范化的，经典结构。但不幸的是，这个并不适用于大型项目。因为如果您的表构建包含许多数据行，例如百万行，取决于您使用的城市或国家，您的联接将非常缓慢。因此，在实际项目中，使用非规范化表，其中包含所有聚合信息。您可以直接使用这些表，也可以使用像sphinx这样的独立服务器来搜索数据。关于三个字段的主键，我认为在这个例子中，这个是多余的。因为

如果您使用

1. ，则此键将添加到此表中的所有辅助键中。如果您使用接口来管理床，则使用一个字段id处理特定行比使用三个字段更方便。如果要保证行的唯一性，则可以在这3个字段上使用唯一的键。

。