MySQL-すべての子テーブルで複数列の主キーを使用する必要がありますか？

このデータは正規化されています

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

この表は（悪い考え）ではありません

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 }

最初の（適切な）テーブルには、不要な重複データはありません。
最初のテーブルへの挿入ははるかに高速になります。
最初のテーブルはメモリに簡単に収まり、クエリが高速化されます。
InnoDBは、モデルBではなくモデルAを念頭に置いて最適化されています。
後者の（悪い）テーブルのデータが重複している場合、 if 同期が外れると、混乱します。 DB Aは、データが1回しかリストされないため、同期が外れるのがはるかに困難になることはありません。
データを結合したい場合建物、床、部屋、ベッドから、モデルAとモデルBの4つのテーブルすべてを組み合わせる必要があります。ここで、どのように時間を節約できますか。
InnoDBは、インデックス付きデータを独自のファイルに保存します。 selectの場合、インデックスのみ 、テーブル自体は決してありませんアクセスされます。では、なぜインデックスを複製するのですか？ MySQLはとにかくメインテーブルを読み取る必要はありません。
InnoDBは、PKをすべてのセカンダリインデックスに保存します 、コンポジットであるため長いPKを使用すると、インデックスを使用するすべての選択が遅くなり、ファイルサイズが大きくなります。何の利益もありません。
深刻な速度の問題がありますか？そうでない場合は、テーブルを非正規化していますか？
これらの問題の影響が少ないMyISAMの使用についても考えないでください。これは、マルチジョインデータベース用に最適化されておらず、参照の不誠実さやトランザクションをサポートしておらず、このワークロードには適していません。
複合キーを使用する場合、キーの右端の部分しか使用できません。つまり、floor_idは使用できません。テーブルbed id+building_id+floor_idを使用する以外、これは、モデルAで必要とされるよりもはるかに多くのキースペースを使用する必要がある可能性があることを意味します。それまたは追加のインデックスを追加する必要があります（PKの完全なコピーをドラッグします）。

要するに
モデルBには、メリットはまったくなく、デメリットもたくさんあります。絶対に使用しないでください。