识别关系会产生太多的密钥？

Question

我有一个工作数据库，除了许多到多个连接之外，我只使用了非标识的关系。无论如何，我必须改变它，所以我想我会在路上改进它；我刚刚读到了非关系和识别关系之间的区别，我已经了解到，在没有父母的情况下，应该使用后者。例如，我有一张“会议”表，它基本上是一组具有一些共同价值的“Votings”--孤独的“会议”是没有权利的，所以我只是在非标识关系上使用级联删除，但现在我加入了它们，使用的是识别关系。所以我做了，和一些其他的表；显然不是所有的表，但不是，我结束了这个表的‘结果’，其中有……11个主键和一个外键！更改前只有三个外键。只有当我不需要回到所有的方法，一表一表的找到根的时候，它才能对管理有所帮助，但是那里会有上千条记录，我想知道它是否会对数据库的性能或大小产生一些真正的影响。这条路走不走？对我来说，当简单的连接表中有这么多数据时，它看起来很奇怪.

​

“成绩”表：

CREATE TABLE IF NOT EXISTS `deputydb`.`Result` (
  `Options_id` INT UNSIGNED NOT NULL,
  `Options_Votings_id` INT UNSIGNED NOT NULL,
  `Options_Votings_legalNumberSets_id` INT NOT NULL,
  `Options_Votings_HeadingsForVotings_id` INT UNSIGNED NOT NULL,
  `Options_Votings_Meetings_id` INT UNSIGNED NOT NULL,
  `Options_Votings_Meetings_Venues_id` INT UNSIGNED NOT NULL,
  `Options_Votings_Meetings_Venues_Settings_id` INT UNSIGNED NOT NULL,
  `Options_Votings_Meetings_HeadingsForMeetings_id` INT UNSIGNED NOT NULL,
  `Microphones_id` INT UNSIGNED NOT NULL,
  `Microphones_Venues_id` INT UNSIGNED NOT NULL,
  `Microphones_Venues_Settings_id` INT UNSIGNED NOT NULL,
  `People_id` INT UNSIGNED NOT NULL,
  PRIMARY KEY (`Options_id`, `Options_Votings_id`, `Options_Votings_legalNumberSets_id`, `Options_Votings_HeadingsForVotings_id`, `Options_Votings_Meetings_id`, `Options_Votings_Meetings_Venues_id`, `Options_Votings_Meetings_Venues_Settings_id`, `Options_Votings_Meetings_HeadingsForMeetings_id`, `Microphones_id`, `Microphones_Venues_id`, `Microphones_Venues_Settings_id`),
  INDEX `fk_Result_Microphones1_idx` (`Microphones_id` ASC, `Microphones_Venues_id` ASC, `Microphones_Venues_Settings_id` ASC),
  INDEX `fk_Result_People1_idx` (`People_id` ASC),
  CONSTRAINT `fk_Result_Options1`
    FOREIGN KEY (`Options_id` , `Options_Votings_id` , `Options_Votings_legalNumberSets_id` , `Options_Votings_HeadingsForVotings_id` , `Options_Votings_Meetings_id` , `Options_Votings_Meetings_Venues_id` , `Options_Votings_Meetings_Venues_Settings_id` , `Options_Votings_Meetings_HeadingsForMeetings_id`)
    REFERENCES `deputydb`.`Options` (`id` , `Votings_id` , `Votings_legalNumberSets_id` , `Votings_HeadingsForVotings_id` , `Votings_Meetings_id` , `Votings_Meetings_Venues_id` , `Votings_Meetings_Venues_Settings_id` , `Votings_Meetings_HeadingsForMeetings_id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Result_Microphones1`
    FOREIGN KEY (`Microphones_id` , `Microphones_Venues_id` , `Microphones_Venues_Settings_id`)
    REFERENCES `deputydb`.`Microphones` (`id` , `Venues_id` , `Venues_Settings_id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Result_People1`
    FOREIGN KEY (`People_id`)
    REFERENCES `deputydb`.`People` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

Answer 1

“改进”取决于具体情况。从纯形式的角度来看，您可能是对的(假设它确实是一个弱实体，并且您的字段是正确的)。然而，在设计、规范化和应用所有良好的设计模式之后，计算机的局限性及其实现就成了事实。

特别是，在InnoDB中，对于该表，将获得3个次要索引，每个索引将存储主键值的全部内容，从而使表的比没有大PK的版本大3倍(而且可能会慢很多倍)。当然，如果您计划只存储几个记录，这将不会是一个问题，但只有几千，差异可能是巨大的。

在这种情况下，从实现的角度和常见的实践来看，使用伪密钥作为主密钥是合理的，无论是“好的设计”还是“好的设计”。这也是为什么有时我们更喜欢为PKs使用数字自动递增键而不是重用已经存在的唯一字符串的原因。然后，通过在应用程序或中间层中实现额外的逻辑来解决大多数设计缺陷，这提供了比MySQL更好的可伸缩性和特性。

Answer 2

这个DB模式是个噩梦..。我不使用这个工具。但是..。

我猜您已经单击了GUI中的每个关系(意思是表之间的行)，并为每个依赖表设置了正确的父键。