Привет! Подскажите, пожалуйста по правильной архитектуре.

Использую noSQL БД - MongoDB

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

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

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

Привет! Подскажите, пожалуйста по правильной архитектуре.

Использую noSQL БД - MongoDB

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

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

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

Странноватый ещё "2)".
Как минимум, потому что это не "Дата".

И странно хранить там именно количество. Что это за дата?
Она определяет ограничение на максимальное количество дня?
Или ячейки дня, когда можно иметь бронь?
Или только количество броней в день?

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

Как формируются такие "даты"? Каждый день уникален? Или есть какие-то паттерны, например, "всю неделю мероприятие А", или "каждый понедельник месяца мероприятие А"?

Если в понедельник 3 мероприятия, то "весь день три" или сначала одно, потом другое, потом третье?
Человек может прийти на мероприятие в любое время, или это как сеансы в кинотеатре?


> Это нужно для удобства администрирования музея
Администратор музея будет работать напрямую в МонгоБД?
Если нет, то его точно не волнует, какая будет структура БД.

Как формируются такие "даты"? Каждый день уникален? Или есть какие-то паттерны, например, "всю неделю мероприятие А", или "каждый понедельник месяца мероприятие А"?

Если в понедельник 3 мероприятия, то "весь день три" или сначала одно, потом другое, потом третье?
Человек может прийти на мероприятие в любое время, или это как сеансы в кинотеатре?


> Это нужно для удобства администрирования музея
Администратор музея будет работать напрямую в МонгоБД?
Если нет, то его точно не волнует, какая будет структура БД.

Привет! Подскажите, пожалуйста по правильной архитектуре.

Использую noSQL БД - MongoDB

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

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

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

Приветствую 🖖🏻

Скажите, пожалуйста, в чем смысл паттерна строитель/builder?

Почему нельзя все делать через сеттеры?
Особенно, если нет директора?

Если вопрос не по теме, укажите, пожалуйста, куда его можно задать.

Что ?

Вопрос про паттерн проектирования Builder (по русски - строитель)

Что вам не понятно, скажите, пожалуйста ?

а директор это кто?

а директор это кто?

Класс, в который инкапсулирована логика создания объекта