MySQL - Moet ik primaire sleutels met meerdere kolommen gebruiken op elke onderliggende tabel?

Deze gegevens zijn genormaliseerd

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

Deze tafel is niet (slecht idee)

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. In de eerste (goede) tabel heb je geen onnodige dubbele gegevens.
2. Invoegingen in de eerste tabel gaan veel sneller.
3. De eerste tabellen passen gemakkelijker in het geheugen, waardoor uw zoekopdrachten sneller gaan.
4. InnoDB is geoptimaliseerd met model A in gedachten, niet met model B.
5. De laatste (slechte) tabel heeft dubbele gegevens, als als dat niet synchroon loopt, krijg je een puinhoop. DB A kan niet veel moeilijker uit de pas lopen, omdat de gegevens maar één keer worden vermeld.
6. Als ik gegevens wil combineren van het gebouw, de verdieping, de kamer en het bed zal ik alle vier de tafels in model A en model B moeten combineren, hoe bespaar je hier tijd?
7. InnoDB slaat geïndexeerde gegevens op in zijn eigen bestand, als u select alleen indexen , zullen de tabellen zelf nooit worden benaderd. Dus waarom dupliceer je de indexen? MySQL zal sowieso nooit de hoofdtabel hoeven te lezen.
8. InnoDB slaat de PK op in elke secundaire index , met een samengestelde en dus lange PK, vertraag je elke selectie die een index gebruikt en vergroot je de bestandsgrootte; voor geen enkele winst.
9. Heeft u een ernstig snelheidsprobleem? Zo niet, denormaliseert u uw tabellen?
10. Denk er niet eens aan om MyISAM te gebruiken, dat minder last heeft van deze problemen, het is niet geoptimaliseerd voor multi-join databases en ondersteunt geen referentiële integriteit of transacties en past slecht bij deze werklast.
11. Als u een samengestelde sleutel gebruikt, kunt u alleen het meest rechtse deel van de sleutel gebruiken, d.w.z. u kunt floor_id niet gebruiken in tafel bed anders dan het gebruik van id+building_id+floor_id , Dit betekent dat u mogelijk veel meer sleutelruimte moet gebruiken dan nodig is in Model A. Ofwel moet u een extra index toevoegen (die een volledige kopie van de PK rondsleept).

Kortom
Ik zie absoluut geen voordelen en een heleboel nadelen in Model B, gebruik het nooit!