Привет! Подскажите, пожалуйста по правильной архитектуре. Использую noSQL БД -

MongoDB

Суть такая, хочу для музея создавать мероприятия, далее распределять мероприятия по дням , далее люди смогу из клинетской части записываться на события и оплачивать бронь (покупать билет) . Пользователь может забронировать сразу несколько разных мероприятий на разных датах.

Получаются следующие модели в MongoDB:
1) Мероприятие, в схеме которого основные данные, вроде описания, длительности, максимальное количество человек, картинки и двусторонняя связь с Датами, на которых будет событие.
2) Дата, где количество записей на этот день, связанное с моделью Бронирования и связь с самим событием. Вопрос, нужно ли тут дублировать в схеме информацию из основного события, в виде длительности, названия и стоимости? Или просто отдельным запросом через связь получать информацию?
3) Бронирование, где уникальная ссылка, связь с Датой и Связь с пользователем. Вопрос, нужно ли дублировать информацию из связанной модели Даты или получать отдельным запросом?
4) Пользователь, связанный с бронированием.

Такая организация сама по себе нормальна? Не избыточна?

Не разбираюсь в проектировании ДОБД, но выглядит, как типичная задача для РБД

рбд и к херам модель даты

Странноватый ещё "2)". Как минимум, потому что это не "Дата". И странно хранить там именно количество. Что это за дата? Она определяет ограничение на максимальное количество дня? Или ячейки дня, когда можно иметь бронь? Или только количество броней в день?

Например, у нас есть несколько стандартных мероприятий в музее. Пусть они будут называться "ШОУ А", "ШОУ Б" и так далее. У них разные стоимости, суть, вместимость человек и длительность. В админке нам нужен календарь, чтобы забить дни недели по событиям, В понедельник пусть будет 3 мероприятия. С 9 утра и по 18.00 с обедом в час. На каждое событие соответственно можно записаться. В данном случае "понедельник" - это как раз и есть модель с датой. Он связан как с моделью бронирования (количество записавшихся пользователей), так и с моделью мероприятий. Это нужно для удобства администрирования музея. Открыть календарь и посмотреть что в планах, сколько ранних бронирования и отредактировать.

Как формируются такие "даты"? Каждый день уникален? Или есть какие-то паттерны, например, "всю неделю мероприятие А", или "каждый понедельник месяца мероприятие А"? Если в понедельник 3 мероприятия, то "весь день три" или сначала одно, потом другое, потом третье? Человек может прийти на мероприятие в любое время, или это как сеансы в кинотеатре? > Это нужно для удобства администрирования музея Администратор музея будет работать напрямую в МонгоБД? Если нет, то его точно не волнует, какая будет структура БД.

Сначала одно, потом другое, потом третье. Я планирую сделать красивую таблицу с разбивкой по временным отрезкам по вертикали и по датам по горизонтали. Плюс фильтрацию всего этого и так далее. Временной отрезок в 15 минут. Если мероприятие "Шоу А" условно длится 2 часа, то его вручную можно разместить на понедельник, например, с 9.45 до 11.45. И так далее по остальным мероприятиям и дням. Конечно будут проверки по часам и длительность. Так же нужны проверки по количеству записи, потому что вместимость ограниченная. В принципе дни будут уникальны и часто редактироваться. Возможно со временем сложится достаточно устойчивое расписание по дням недели.

Нет, напрямую в БД работать не будет. Просто я хочу правильно организовать, чтобы было по красоте и оптимизированно, а не кое как )

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