MySQL - Skal jeg bruge primære nøgler med flere kolonner på alle underordnede tabeller?

Disse data er normaliseret

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

Denne tabel er ikke (dårlig idé)

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. I den første (gode) tabel har du ikke unødvendige duplikerede data.
2. Indsættelser i den første tabel vil være meget hurtigere.
3. De første tabeller passer lettere i hukommelsen, hvilket gør dine forespørgsler hurtigere.
4. InnoDB er optimeret med model A i tankerne, ikke med model B.
5. Sidstnævnte (dårlige) tabel har duplikerede data, hvis der kommer ud af synkronisering, vil du have noget rod. DB A kan ikke er meget sværere at komme ud af synkronisering, fordi dataene kun er listet én gang.
6. Hvis jeg vil kombinere data fra bygning, gulv, værelse og seng skal jeg kombinere alle fire borde i model A samt model B, hvordan sparer du tid her.
7. InnoDB gemmer indekserede data i sin egen fil, hvis du select kun indekser , vil selve tabellerne aldrig blive tilgået. Så hvorfor dublerer du indekserne? MySQL behøver aldrig at læse hovedtabellen alligevel.
8. InnoDB gemmer PK'en i hvert sekundært indeks , med en sammensat og dermed lang PK, bremser du hvert valg, der bruger et indeks, og reducerer filstørrelsen; uden nogen som helst gevinst.
9. Har du et alvorligt hastighedsproblem? Hvis ikke, denormaliserer du dine borde?
10. Tænk ikke engang på at bruge MyISAM, som lider mindre af disse problemer, det er ikke optimeret til multi-join-databaser og understøtter ikke referentiel integritet eller transaktioner og passer dårligt til denne arbejdsbyrde.
11. Når du bruger en sammensat nøgle, kan du kun bruge den yderste højre del af nøglen, dvs. du kan ikke bruge floor_id i tabel bed andet end at bruge id+building_id+floor_id , Det betyder, at du muligvis skal bruge meget mere nøglerum end nødvendigt i Model A. Enten det, eller også skal du tilføje et ekstra indeks (som vil trække rundt i en hel kopi af PK).

Kort sagt
Jeg ser absolut ingen fordele og en masse ulemper ved Model B, brug den aldrig!