ModelR- и проч. и проч.

совершенно верно.

вчера было набросал модельку: на 3 корпуса 1 -2 -3 этажа и один инженерный...

набил данных на один корпус: 12 1-х номеров 12 2-х номеров 4 Люкса Бассейн и различные вспомогательные помещения, всего Premises порядка 70-80...

в принципе подход с зонированием оправдан - получается довольно занятно, но, действительно, очень сложен в сопровождении - я и сам запутался на втором десятке объектов рассовывая их в первый десяток зон

пришлось набросать на бумажке эскиз "реальной гостиницы" - все стало гораздо проще и понятнее - т.е. выручить может смена парадигмы интерфеса - не классические формы ввода, а планы помещений и схемы расположения зон...

еще один момент, вероятно лучше будет совместить два подхода в организации схемы данных

tblLocations - жесткая иерархическая структура Parent-Child для хранения данных вида Building<Block<Unit<Place - каждая койка на своем и только своем месте

и более гибкая - Many-to-Many на основе таблицы tblAreas - каждое помещение учтено в разных категориях - кто убирает, кто охраняет, в зоне какого класса расположено.

во всяком случае задача

уборку номеров "Super Lux Queen Elizabeth" поручать только специально обученым людям, на каком бы этаже номер не находился

решается в лет - создаем новую зону уборки

AreaID C # 2348
AreaType CleaningZone
AreaCategory Professional Cleaning

и напихиваем в нее номера "Super Lux Queen Elizabeth"

PremiseID R # 56789
PremiseType Residence
PremiseCategory SuperLux

и прилегающие помещения

PremiseID S # 77659
PremiseType SharedZone
PremiseCategory Regular

PremiseID S # 77654
PremiseType Recreation
PremiseCategory Regular

Чернышев Андрей ЛеонидовичЛовко.

Андрей Леонидович, не нужно передергивать :)

я, конечно, не дурак и послать кого след куда след, но к их числу вы не относитесь...