За последние 24 часа нас посетили 20818 программистов и 1131 робот. Сейчас ищут 422 программиста ...

Как правильно спроектировать архитектуру?

Тема в разделе "MySQL", создана пользователем myks92, 8 июн 2019.

Метки:
  1. myks92

    myks92 Новичок

    С нами с:
    12 июн 2018
    Сообщения:
    45
    Симпатии:
    1
    Всем привет)

    Прощу помощи и критики в архитектуре таблиц.
    Небольшое слово о ТЗ.

    Необходимо реализовать Календарь мероприятий с регистрацией на них. Примерно 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-нами. Нужно будет много таблиц подгружать чтобы вывести, например, у участника список мероприятий, в которых он принимал участие, где нужно будет вывести название мероприятия, период, дисциплина... что посоветуете в этом случае? Если же оставить так, то нам придётся сначала делать запрос в систему регистраций, затем в периоды и только тогда мы по связи получим название мероприятия.

    Посоветуйте что нибудь ещё. Давно голову ломаю( Очень нужна помощь специалистов!!!
     
  2. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.068
    Симпатии:
    1.231
    Адрес:
    там-сям
    Хорошая тема, подписываюсь. Схема вроде рабочая.

    Первое замечание: возможно вы занимаетесь преждевременной оптимизацией и на самом деле всё будет достаточно быстро работать без доп. усилий.

    Оптимизировать выборку дополнительных полей можно за счёт намеренной де-нормализации: Оставляем существующие таблицы как есть, но добавляем поля со справочной информацией чтобы избежать джойнов. Например в таблице Участники добавляем поле Личные_мерориятия . В нем будут дублироваться необходимые данные из связки Мероприятия-Дисциплина. Инфа например в json. Важно не пытаться использовать такие поля для фильтрации, но только в целях быстрого вывода. Таким образом придется усложнить добавление данных, но это позволит ускорить самые востребованные выборки.

    Ещё раз: возможно на начальном этапе не стоит этим заморачиваться, просто имейте в виду как "план Б".
     
    myks92 нравится это.
  3. myks92

    myks92 Новичок

    С нами с:
    12 июн 2018
    Сообщения:
    45
    Симпатии:
    1
    Благодарю за помощь)))) Возможно и правда рано думать об оптимизации. Но я в целом не сильно разбираюсь в базах, поэтому лучше переспрошу лишний раз на всякий случай) Теперь все понятно)
     
  4. Valick

    Valick Активный пользователь

    С нами с:
    12 авг 2018
    Сообщения:
    1.911
    Симпатии:
    328
    @myks92, грамотная организация БД - это 50% работы над проектом. Первые 15% - это до начала написания кода, остальные 35% в процессе вплоть до релиза. С первыми 15%-ю процентами вы справились, надеюсь теперь понимаете, что это ничего не значит.
     
  5. myks92

    myks92 Новичок

    С нами с:
    12 июн 2018
    Сообщения:
    45
    Симпатии:
    1
    Конечно, я это понимаю))