MySQL:¿debería usar claves principales de varias columnas en cada tabla secundaria?

Estos datos están normalizados

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

Esta tabla no es (mala idea)

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. En la primera tabla (buena) no tiene datos duplicados innecesarios.
2. Las inserciones en la primera tabla serán mucho más rápidas.
3. Las primeras tablas caben más fácilmente en la memoria, lo que acelera las consultas.
4. InnoDB está optimizado con el modelo A en mente, no con el modelo B.
5. La última tabla (mala) tiene datos duplicados, si que se desincroniza, tendrás un lío. DB A no puede ser mucho más difícil de sincronizar, porque los datos solo se enumeran una vez.
6. Si quiero combinar datos desde el edificio, el piso, la habitación y la cama, necesitaré combinar las cuatro mesas en el modelo A y el modelo B, ¿cómo estás ahorrando tiempo aquí?
7. InnoDB almacena datos indexados en su propio archivo, si select solo índices , las propias tablas nunca ser accedido. Entonces, ¿por qué estás duplicando los índices? MySQL nunca necesitará leer la tabla principal de todos modos.
8. InnoDB almacena el PK en cada índice secundario , con un PK compuesto y, por lo tanto, largo, está ralentizando cada selección que usa un índice y aumentando el tamaño del archivo; sin ganancia alguna.
9. ¿Tiene problemas graves de velocidad? Si no, ¿estás desnormalizando tus tablas?
10. Ni siquiera piense en usar MyISAM, que sufre menos de estos problemas, no está optimizado para bases de datos de unión múltiple y no admite transacciones o integridad referencial y no es una buena opción para esta carga de trabajo.
11. Cuando usa una clave compuesta, solo puede usar la parte más a la derecha de la clave, es decir, no puede usar floor_id en mesa bed aparte de usar id+building_id+floor_id , Esto significa que es posible que deba usar mucho más espacio de teclas que el necesario en el Modelo A. O eso o necesita agregar un índice adicional (que arrastrará una copia completa del PK).

En resumen
Veo absolutamente cero beneficios y muchos inconvenientes en el Modelo B, ¡nunca lo use!