Всем привет) Прощу помощи и критики в архитектуре таблиц. Небольшое слово о ТЗ. Необходимо реализовать Календарь мероприятий с регистрацией на них. Примерно 800 мероприятий в год. Около 1000 заявок на каждый период. В каждой заявке может быть от 1 до 100 участников. База mysql. Нюансы: - мероприятия могут быть разовые, а могут быть переодичные (ежедневные, ежегодные, ежемесячные...). Период указывается датой и временем. Дубликаты мероприятий запрещены. - На мероприятие есть несколько типов регистраций: соревнование, мастер-класс, батл. Типы регистрации закрепляются за периодом мероприятия. - В личном кабинете участников выводится история участия (название мероприятия, дата из периода, название дисциплины ещё будет какое место занял, но это пока не указано). В личном кабинете регистратора выводится список заявок. - Необходимо управлять дисциплинами мероприятия. На какие можно регистрироваться, а какие нет. Для этого отдельная таблица. Там же будет сразу считаться сколько участников в дисциплине. Какие разделы задействованы? 1. Организации (organizations) 2. Люди организации (organization_persons) 3. Дисциплины (disciplines связующая таблица с отдельными таблицами ages, kidns, levels, nominations) 4. Города 5. Мероприятия (events) 6. Периоды мероприятия/даты проведения (event_periods) 7. Система регистраций - здесь создаем различные сервисы для регисрации. Регистрации могут быть: соревнования, батлы, мастер-классы ... (registrations) 8. Заявки регистрации (reg_turn_request) 9. Дисциплины регистрации (reg_turn_discitplines) ссылается на таблицу дисциплин и получение полного названия через метод getName() Вот что у меня получилось. https://dbdiagram.io/d/5cfad2ca09a99609d6145a6a В чем собствннно сложность? 1. Это архитектура. На сколько правильно она выстроена. Есть ли какие-то косяки? 2. Запросы. Меня больше именно волнует этот фактор. Так как данные разбросаны по разным таблицам и будет возня по join-нами. Нужно будет много таблиц подгружать чтобы вывести, например, у участника список мероприятий, в которых он принимал участие, где нужно будет вывести название мероприятия, период, дисциплина... что посоветуете в этом случае? Если же оставить так, то нам придётся сначала делать запрос в систему регистраций, затем в периоды и только тогда мы по связи получим название мероприятия. Посоветуйте что нибудь ещё. Давно голову ломаю( Очень нужна помощь специалистов!!!
Хорошая тема, подписываюсь. Схема вроде рабочая. Первое замечание: возможно вы занимаетесь преждевременной оптимизацией и на самом деле всё будет достаточно быстро работать без доп. усилий. Оптимизировать выборку дополнительных полей можно за счёт намеренной де-нормализации: Оставляем существующие таблицы как есть, но добавляем поля со справочной информацией чтобы избежать джойнов. Например в таблице Участники добавляем поле Личные_мерориятия . В нем будут дублироваться необходимые данные из связки Мероприятия-Дисциплина. Инфа например в json. Важно не пытаться использовать такие поля для фильтрации, но только в целях быстрого вывода. Таким образом придется усложнить добавление данных, но это позволит ускорить самые востребованные выборки. Ещё раз: возможно на начальном этапе не стоит этим заморачиваться, просто имейте в виду как "план Б".
Благодарю за помощь)))) Возможно и правда рано думать об оптимизации. Но я в целом не сильно разбираюсь в базах, поэтому лучше переспрошу лишний раз на всякий случай) Теперь все понятно)
@myks92, грамотная организация БД - это 50% работы над проектом. Первые 15% - это до начала написания кода, остальные 35% в процессе вплоть до релиза. С первыми 15%-ю процентами вы справились, надеюсь теперь понимаете, что это ничего не значит.