MySQL - Dois-je utiliser des clés primaires multi-colonnes sur chaque table enfant ?

Ces données sont normalisées

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

Ce tableau n'est pas (mauvaise idée)

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. Dans le premier (bon) tableau, vous n'avez pas de données dupliquées inutiles.
2. Les insertions dans le premier tableau seront beaucoup plus rapides.
3. Les premières tables s'adapteront plus facilement à la mémoire, ce qui accélérera vos requêtes.
4. InnoDB est optimisé avec le modèle A à l'esprit, pas avec le modèle B.
5. Cette dernière (mauvaise) table contient des données en double, si qui se désynchronise, vous aurez un gâchis. DB A ne peut pas être beaucoup plus difficile à désynchroniser, car les données ne sont répertoriées qu'une seule fois.
6. Si je veux combiner des données du bâtiment, du sol, de la chambre et du lit, je devrai combiner les quatre tables du modèle A ainsi que du modèle B, comment gagnez-vous du temps ici.
7. InnoDB stocke les données indexées dans son propre fichier, si vous select uniquement les index , les tables elles-mêmes ne seront jamais être accessible. Alors pourquoi dupliquez-vous les index ? MySQL n'aura jamais besoin de lire la table principale de toute façon.
8. InnoDB stocke le PK dans chaque index secondaire , avec un PK composite et donc long, vous ralentissez chaque sélection qui utilise un index et augmentez la taille du fichier ; pour aucun gain quoi que ce soit.
9. Avez-vous un sérieux problème de vitesse ? Sinon, êtes-vous en train de dénormaliser vos tables ?
10. Ne pensez même pas à utiliser MyISAM qui souffre moins de ces problèmes, il n'est pas optimisé pour les bases de données à jointures multiples et ne prend pas en charge l'intégrité référentielle ou les transactions et ne correspond pas à cette charge de travail.
11. Lorsque vous utilisez une clé composite, vous ne pouvez utiliser que la partie la plus à droite de la clé, c'est-à-dire que vous ne pouvez pas utiliser floor_id dans le tableau bed autre que l'utilisation de id+building_id+floor_id , Cela signifie que vous devrez peut-être utiliser beaucoup plus d'espace clé que nécessaire dans le modèle A. Soit cela, soit vous devez ajouter un index supplémentaire (qui entraînera une copie complète du PK).

En bref
Je ne vois absolument aucun avantage et beaucoup d'inconvénients dans le modèle B, ne l'utilisez jamais !