Часто бывает что выгодно делать именно денормалазацию данных. Тут как везде борьба компромиссов.
Я тут накидаю своих размышлений а у вас будет почва для дополнительных раздумий.
Для наглядности я сюда схему прикрепил
Нормализация
Группы, инструменты, музыканты сейчас нормализованы, и они храняться в отдельных таблицах.
Преимущества:
- Мы можем переиспользывать эти данные
- В других таблицах, это внешний ключ и мы получаем индекс
- База следит за целостностью информации(то есть, если мы добавляем новый состав, группа должна существовать. Если мы захотим удалить группу, база данных может нам запретить это сделать так как у нас есть записи в таблице состав группы. Это уже настройки restrict or update) На первый взгляд не самое очевидное, но важное преимущество тем не менее.
И вот почему, мы можем денормализовать эти таблицы, добавляя как строку в pivot table(таблица составов и остальные что ниже на диаграмме) вместо внешнего ключа:
- Меньше запросов при insert
- Если сделать индекс, не надо ходить за id в верхние таблицы, но ...
Собственно весь мир стремиться к хаосу и код не исключение. Давая повод для вставки простой строки, мы провоцируем все это на хаос. Может вы знаете конечный список групп, но кто то не знает и может вставить что угодно, соответственно из за этого будет проблемы.
Подход от бизнеса
Стоит учитывать так же, что не всегда и не везде нужны например составы групп. Возможно требуется только актуальный сейчас, а те что были хранятся для истории. Тогда схему можно переорганизовать, и добавить хранение только текущих музыкантов, а историю с логом выносить в другое место.
Следует задавать себе вопросы:
- А как может быть дальше?
- Какие могут быть выборки, вставки, добавление и далее?(возможно вам надо выбрать другой тип хранения, где отсутствует транзакции и очень быстрая выборка(MyISAM для примера)
- Какое кол-во данных будет храниться?Что будет добавлять регулярно а что нет?
И многие другие вопросы(они будут увеличиться с опытом)
Отчасти усложнять сис-му в начале не стоит(но думать об этом надо), добавить индексы, денормализацию и так далее, делают скорее после под обстоятельства.
Работа в самом коде
Возможно вас пугает кол-во вставок при такой архитектуре. Это реляционная база данных, и связи одно из главных вещей(преимуществ) и она отражена в названии.
В коде это организуется конечно иначе, в зависимости от использования подхода к работе с базой.
Это может быть:
- Active Record(Eloquent - laravel)
- Data mapping (Doctrina - Symfony)
Не углубляясь в подробности, часть будет инкапсулирована и вставка будет проще(в самом коде).
Зависит так же от интерфейса, при том примере что у вас выше:
В окне пользователя будет вводиться сразу вся информация.
И это не всегда так, в зависимости от подхода(может быть SPA приложение), в одном окне может добавляться состав группы, в другом из form select, набираться музыканты в этот состав.
Резюмируя - реляционная база это кончено связи. Можете попробовать организовать такое в NoSQL. Таблицы что выше, кто - то называет их справочниками.(можно организовать кэш по ним, если они не изменяются, а только переиспользуются и добавляются новые).
Надеюсь хоть в чем то вам помог.
Простой
