MySQL – Mám používat vícesloupcové primární klíče na každé podřízené tabulce?

Tato data jsou normalizována

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

Tato tabulka není (špatný nápad)

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. V první (dobré) tabulce nemáte nepotřebná duplicitní data.
2. Vložení v první tabulce bude mnohem rychlejší.
3. První tabulky se snáze vejdou do paměti, což urychlí vaše dotazy.
4. InnoDB je optimalizován s ohledem na model A, nikoli s modelem B.
5. Poslední (špatná) tabulka obsahuje duplicitní data, pokud že se to nesynchronizuje, budete mít nepořádek. DB A can je mnohem těžší dostat mimo synchronizaci, protože data jsou uvedena pouze jednou.
6. Pokud chci kombinovat data z budovy, podlahy, pokoje a postele budu muset zkombinovat všechny čtyři stoly v modelu A i modelu B, jak zde šetříte čas.
7. InnoDB ukládá indexovaná data do vlastního souboru, pokud select pouze indexy , samotné tabulky nikdy nebudou být přístupný. Proč tedy duplikujete indexy? MySQL stejně nikdy nebude muset číst hlavní tabulku.
8. InnoDB ukládá PK v každém sekundárním indexu , se složeným a tedy dlouhým PK zpomalíte každý výběr, který používá index, a zvětšíte velikost souboru; pro žádný zisk.
9. Máte vážný problém s rychlostí? Pokud ne, denormalizujete své tabulky?
10. Ani nepřemýšlejte o použití MyISAM, který těmito problémy trpí méně, není optimalizován pro databáze s více připojeními a nepodporuje referenční integritu nebo transakce a pro tuto zátěž se nehodí.
11. Při použití složeného klíče můžete vždy použít pouze pravou část klíče, tj. nemůžete použít floor_id v tabulce bed jinak než pomocí id+building_id+floor_id , To znamená, že možná budete muset použít mnohem více místa na klíče, než je potřeba v modelu A. Buď to, nebo budete muset přidat další index (který přetáhne celou kopii PK).

Ve zkratce
V modelu B vidím absolutně nulový přínos a spoustu nevýhod, nikdy jej nepoužívejte!