识别关系会创建太多密钥？

Question

我有一个工作数据库，我只使用非识别关系，除了多对多连接。无论如何我不得不对它做出改变，所以我想我会在途中改进它;我刚刚读到了非关系和识别关系之间的区别，并且我已经知道后者应该用于没有父母的孩子不能存在的地方。而且，例如，我有“会议”表，这基本上是一组具有一些共同价值观的“投票” - 孤独的“会议”没有权利这样我只是在非识别关系上使用级联删除，但现在我和他们一起使用了识别一个。所以我做了一些其他表;显然不是所有这些，但不是我最终得到了这个'结果'表，它有...... 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

这个数据库架构是一场噩梦...... 我不使用这个工具。但是...

我猜你已经点击了GUI中的每个关系（表示为表之间的行） 并为EACH依赖表设置正确的PARENT KEY。

Answer 2

“改善”取决于具体情况。从纯正式的角度来看，你可能是对的（假设它实际上是一个弱实体，你的领域是正确的）。然而，在设计之后，所有良好设计模式的规范化和应用都会带来关于计算机限制及其实现的真相。

特别是在InnoDB中，对于该表，您将获得3个二级索引，每个索引将存储主键值的全部内容，从而导致表格大3倍（和可能比没有大PK的版本慢很多倍。当然，如果你打算只存储一些记录就不会有问题，但只有几千个差异可能会很大。

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