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 }

1. В първата (добра) таблица нямате ненужни дублирани данни.
2. Вмъкванията в първата таблица ще бъдат много по-бързи.
3. Първите таблици ще се поберат по-лесно в паметта, ускорявайки заявките ви.
4. InnoDB е оптимизиран с модел А, а не с модел Б.
5. Последната (лоша) таблица има дублирани данни, if което излезе от синхрон, ще имате бъркотия. DB A не може е много по-трудно да се излезе от синхронизация, тъй като данните са изброени само веднъж.
6. Ако искам да комбинирам данни от сградата, етажа, стаята и леглото ще трябва да комбинирам и четирите маси в модел А, както и модел Б, как спестявате време тук.
7. InnoDB съхранява индексирани данни в свой собствен файл, ако select само индекси , самите таблици щеникога бъде достъпна. Тогава защо дублираш индексите? MySQL така или иначе никога няма да има нужда да чете основната таблица.
8. InnoDB съхранява PK във всеки вторичен индекс , със съставен и следователно дълъг PK, вие забавяте всеки избор, който използва индекс и увеличавате размера на файла; за никаква печалба каквото и да било.
9. Имате ли сериозен проблем със скоростта? Ако не, вие денормализирате ли таблиците си?
10. Дори не си и помисляйте да използвате MyISAM, който страда по-малко от тези проблеми, той не е оптимизиран за бази данни с множество обединения и не поддържа референтна цялост или транзакции и не съответства на това работно натоварване.
11. Когато използвате съставен ключ, можете да използвате само най-дясната част на ключа, т.е. не можете да използвате floor_id в таблица bed различни от използването на id+building_id+floor_id , Това означава, че може да се наложи да използвате много повече ключово пространство, отколкото е необходимо в Модел A. Или това, или трябва да добавите допълнителен индекс (който ще плъзга около пълно копие на PK).

Накратко
Виждам абсолютно нулева полза и много недостатъци в Model B, никога не го използвайте!