MySQL - Sollte ich mehrspaltige Primärschlüssel für jede untergeordnete Tabelle verwenden?

Diese Daten sind normalisiert

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

Diese Tabelle ist nicht (schlechte 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 der ersten (guten) Tabelle haben Sie keine unnötigen doppelten Daten.
2. Einfügungen in die erste Tabelle werden viel schneller sein.
3. Die ersten Tabellen passen leichter in den Speicher und beschleunigen Ihre Abfragen.
4. InnoDB ist für Modell A optimiert, nicht für Modell B.
5. Die letzte (schlechte) Tabelle hat doppelte Daten, wenn das aus dem Takt gerät, wirst du ein Durcheinander haben. DB A kann nicht viel schwerer aus dem Takt geraten, weil die Daten nur einmal aufgelistet werden.
6. Wenn ich Daten kombinieren möchte aus Gebäude, Etage, Zimmer und Bett muss ich alle vier Tische in Modell A sowie Modell B kombinieren, wie sparen Sie hier Zeit?
7. InnoDB speichert indizierte Daten in einer eigenen Datei, wenn Sie select nur Indizes , die Tabellen selbst nie zugegriffen werden. Warum duplizieren Sie also die Indizes? MySQL wird sowieso nie die Haupttabelle lesen müssen.
8. InnoDB speichert den PK in jedem sekundären Index , mit einem zusammengesetzten und damit langen PK verlangsamen Sie jede Auswahl, die einen Index verwendet, und erhöhen die Dateigröße; für keinen Gewinn, was auch immer.
9. Haben Sie ernsthafte Geschwindigkeitsprobleme? Wenn nicht, denormalisieren Sie Ihre Tabellen?
10. Denken Sie nicht einmal daran, MyISAM zu verwenden, das weniger unter diesen Problemen leidet, es ist nicht für Multi-Join-Datenbanken optimiert und unterstützt keine referenzielle Integrität oder Transaktionen und ist für diese Arbeitslast schlecht geeignet.
11. Wenn Sie einen zusammengesetzten Schlüssel verwenden, können Sie immer nur den ganz rechten Teil des Schlüssels verwenden, d. h. Sie können floor_id nicht verwenden im Tisch bed außer id+building_id+floor_id , Dies bedeutet, dass Sie möglicherweise viel mehr Schlüsselraum verwenden müssen, als in Modell A benötigt wird. Entweder das, oder Sie müssen einen zusätzlichen Index hinzufügen (der eine vollständige Kopie des PK herumschleppt).

Kurz gesagt
Ich sehe absolut keinen Nutzen und eine ganze Menge Nachteile in Modell B, benutze es niemals!