maximw

Делать внутри транзакции или вешать триггер

Должно быть две сущности - бронирование и тайм-слот.
У бронирования должен быть признак периодичности и ее настройки.
У тайм-слота должна быть ссылка на бронирование, пустая или занятая.
Тайм-слоты должны быть заранее созданы на будущее, в пределах которого может осуществляться бронирование.

При создании бронирования, всем подходящим по расписанию тайм-слотам ставится ссылка на бронирование.
При удалении бронирования. соотв. ссылки удаляются.
Важно при создании бронирования просмотреть возможность занять нужные тайм-слоты и как-то обработать ситуацию когда хотя бы один тайм-слот не может быть занят в соответствии с расписанием.

Храните массив цен по каждому дню отдельно. В интерфейсе редактирования цен менеджер может задать диапазон дат и цены, но при записи надо отдельно перезаписывать каждый день в БД. Тогда при подсчете общей стоимости бронирования это будет простой проход в цикле по всем дням периода бронирования с простым суммированием соотв. цен.
Возрастает объем хранимых данных, но это очень немного. Возрастает сложность при обновлении цен, хотя возможно наоборот падает в том плане что не надо пересчитывать как вновь заданный диапазон дат ложится на имеющиеся уже записи. И самое главное вы вообще убираете мороку с высчитыванием диапазона дат при вычислении стоимости бронирования.

Вероятно у одного из юзеров есть город которого нет с таблице городов.

Проверить можно запросом:

SELECT * FROM users AS u LEFT JOIN cities AS c ON u.city_id = c.city_id WHERE c.city_id IS NULL

MySQL же говорит в чем ошибка.
У столбцов title и message одинаковые collations?