識別關係會產生太多密鑰？

我有一個工作數據庫，我只使用非識別關係，除了多對多連接。無論如何，我必須改變它，所以我想我會在路上改進它;我剛剛讀到了非識別關係與識別關係之間的區別，我已經瞭解到後者應該用在沒有父母的情況下孩子不能存在的地方。舉例來說，我有一個'會議'表，基本上是一組具有一些共同價值的'Votings' - 孤獨'Meeting'沒有權利，所以我只是在非識別關係上使用級聯刪除，但現在我已經加入了他們用於識別一個。所以我做了一些其他的表格。顯然不是所有的人，但不是我結束了這張「結果」表，它有... 11個主鍵和一個外鍵！變更前只有三個外鍵。如果我不必一路一路回去找到根源，那麼它確實只對管理有所幫助，但是會有成千上萬的記錄，我想知道它是否會產生一些真正的影響。性能或數據庫的大小。這是否要走？對我來說，它只是看起來奇怪，當簡單的連接表中有如此多的數據... The database looks like this now. 識別關係會產生太多密鑰？

「結果」表：

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;

來源

2014-07-23 smsware

「其中有... 11個主鍵」我明白你在說什麼，但聽起來很不對。更好地使用「帶11個字段的複合主鍵」。 – jynus

「改進」取決於上下文。從純粹的形式角度來看，你可能是對的（假設它確實是一個弱實體，你的領域是正確的）。然而，在設計之後，所有優秀設計模式的規範化和應用都會成爲計算機限制及其實現的真相。

特別地，在InnoDB的，該表，你將得到3個二級索引其中它們中的每將存儲主鍵值的完整內容，產生表3倍（和潛在的許多倍比沒有大PK的版本慢）。當然，如果你打算存儲幾條記錄，這不會是一個問題，但只有幾千條，這個差別可能是巨大的。

在這種情況下，從實施的角度和普遍的做法來看，使用pseudokey作爲主鍵是合理的，不管它是否是「好的設計」。這就是爲什麼有時我們更喜歡使用數字自動遞增鍵來替代重用已存在的唯一字符串的原因。然後，通過在應用程序或中間層中實現額外的邏輯來解決大多數設計缺陷，這比MySQL提供了更好的可伸縮性和功能。

來源

2014-07-23 09:22:03 jynus

我不會使用pseudokey，因爲我的應用程序一直不能在數據庫上工作......它下載所有數據，然後上傳更改。所以在此期間它需要給項目一些id值。你是對的 - 如果它自己管理數據庫，那麼測試MySQL引擎是沒有意義的。我只是認爲它會簡單地適應未來的變化。 – smsware

這DB模式是一場噩夢...... 我不不要使用這個工具。但...

我猜你已經點擊了GUI中的每個關係（意思是表格之間的連線），併爲每個依賴表設置適當的父項。

來源

2014-07-23 09:20:45

識別關係會產生太多密鑰？

回答

相關問題