MySQL – Ska jag använda primärnycklar med flera kolumner på alla underordnade tabeller?

Dessa data är normaliserade

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

Denna tabell är inte (dålig 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örsta (bra) tabellen har du inte onödiga duplicerade data.
2. Infogningar i den första tabellen kommer att gå mycket snabbare.
3. De första tabellerna kommer att passa lättare i minnet, vilket påskyndar dina frågor.
4. InnoDB är optimerad med modell A i åtanke, inte med modell B.
5. Den senare (dåliga) tabellen har dubblerade data, if som blir ur synk, kommer du att ha en enda röra. DB A kan inte är mycket svårare att få ur synk, eftersom data bara listas en gång.
6. Om jag vill kombinera data från byggnad, golv, rum och säng kommer jag behöva kombinera alla fyra borden i modell A samt modell B, hur sparar du tid här.
7. InnoDB lagrar indexerad data i sin egen fil, om du select endast index , själva tabellerna aldrig kunna nås. Så varför duplicerar du indexen? MySQL kommer aldrig att behöva läsa huvudtabellen ändå.
8. InnoDB lagrar PK i varje sekundärt index , med en sammansatt och därmed lång PK, saktar du ner varje val som använder ett index och minskar filstorleken; utan någon vinning.
9. Har du allvarliga hastighetsproblem? Om inte, avnormaliserar du dina tabeller?
10. Tänk inte ens på att använda MyISAM som lider mindre av dessa problem, den är inte optimerad för multi-join-databaser och stöder inte referensintegritet eller transaktioner och är en dålig matchning för denna arbetsbelastning.
11. När du använder en sammansatt nyckel kan du bara använda den högra delen av nyckeln, d.v.s. du kan inte använda floor_id i tabell bed annat än att använda id+building_id+floor_id , Detta betyder att du kan behöva använda mycket mer nyckelutrymme än vad som behövs i modell A. Antingen det eller så måste du lägga till ett extra index (som drar runt en hel kopia av PK).

Kort sagt
Jag ser absolut ingen fördel och en hel del nackdelar med Model B, använd den aldrig!