Илья Чубаров

Начальный вариант это нормализованные таблицы
Например:
- Таблица car_make
- Таблица car_model
Где в car_model есть поле car_make_id, это внешний ключ и он уже имеет индекс.
Далее вы выводите список(form select) из вашей таблицы или поиском(пользователь вводить начало названия) по таблице в car_make
Пользователь выбирает определенную марку, в таблице car_model вы можете по id выдать список всех моделей.
Что касательно дат, реализовать можно по разному.
В вашем файле у вас фиксированный диапазон и его можно добавить в таблицу car_model двумя колонками.
Если модель может иметь несколько диапазонов выпуска, можно это хранить в отдельной таблице, где поля будут такие:
car_model_id, start_date, finish_date
Соответственно при выборе в интерфейсе определенной модели, мы можем выбрать список с диапазонами дат.
Правильных ответов тут нет, и зависит от целей, какие могут быть перспективы и так далее.

Например в одном моем проекте был похожий функционал. И использование такой формы, показало что разные марки и модели могут по-разному вводиться пользователями, для примера есть лада и ваз.
И пользователь будет вводить всегда свою версию.
В таком случае для каждой модели и марки пришлось заводить отдельные таблицы - словари.
Где версия пользователя, хранила ссылку на стандартную версию.
То есть у нас была Лада.
Соответственно:
ВАЗ = Лада
Лада = Лада
Kalina - Калина

Часто бывает что выгодно делать именно денормалазацию данных. Тут как везде борьба компромиссов.
Я тут накидаю своих размышлений а у вас будет почва для дополнительных раздумий.
Для наглядности я сюда схему прикрепил


Нормализация
Группы, инструменты, музыканты сейчас нормализованы, и они храняться в отдельных таблицах.
Преимущества:
- Мы можем переиспользывать эти данные
- В других таблицах, это внешний ключ и мы получаем индекс
- База следит за целостностью информации(то есть, если мы добавляем новый состав, группа должна существовать. Если мы захотим удалить группу, база данных может нам запретить это сделать так как у нас есть записи в таблице состав группы. Это уже настройки restrict or update) На первый взгляд не самое очевидное, но важное преимущество тем не менее.
И вот почему, мы можем денормализовать эти таблицы, добавляя как строку в pivot table(таблица составов и остальные что ниже на диаграмме) вместо внешнего ключа:
- Меньше запросов при insert
- Если сделать индекс, не надо ходить за id в верхние таблицы, но ...
Собственно весь мир стремиться к хаосу и код не исключение. Давая повод для вставки простой строки, мы провоцируем все это на хаос. Может вы знаете конечный список групп, но кто то не знает и может вставить что угодно, соответственно из за этого будет проблемы.

Подход от бизнеса
Стоит учитывать так же, что не всегда и не везде нужны например составы групп. Возможно требуется только актуальный сейчас, а те что были хранятся для истории. Тогда схему можно переорганизовать, и добавить хранение только текущих музыкантов, а историю с логом выносить в другое место.
Следует задавать себе вопросы:
- А как может быть дальше?
- Какие могут быть выборки, вставки, добавление и далее?(возможно вам надо выбрать другой тип хранения, где отсутствует транзакции и очень быстрая выборка(MyISAM для примера)
- Какое кол-во данных будет храниться?Что будет добавлять регулярно а что нет?
И многие другие вопросы(они будут увеличиться с опытом)
Отчасти усложнять сис-му в начале не стоит(но думать об этом надо), добавить индексы, денормализацию и так далее, делают скорее после под обстоятельства.

Работа в самом коде
Возможно вас пугает кол-во вставок при такой архитектуре. Это реляционная база данных, и связи одно из главных вещей(преимуществ) и она отражена в названии.
В коде это организуется конечно иначе, в зависимости от использования подхода к работе с базой.
Это может быть:
- Active Record(Eloquent - laravel)
- Data mapping (Doctrina - Symfony)
Не углубляясь в подробности, часть будет инкапсулирована и вставка будет проще(в самом коде).
Зависит так же от интерфейса, при том примере что у вас выше:
В окне пользователя будет вводиться сразу вся информация.
И это не всегда так, в зависимости от подхода(может быть SPA приложение), в одном окне может добавляться состав группы, в другом из form select, набираться музыканты в этот состав.
Резюмируя - реляционная база это кончено связи. Можете попробовать организовать такое в NoSQL. Таблицы что выше, кто - то называет их справочниками.(можно организовать кэш по ним, если они не изменяются, а только переиспользуются и добавляются новые).
Надеюсь хоть в чем то вам помог.