Приветы! У меня есть вопрос, который несколько выходит за пределы моих

точных познаний по проектированию баз данных.

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

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

Итого, на языке сущностей, у меня получается:
- есть некоторая центральная сущность, назовём её InsuranceDetails.
- есть 6 разных сущностей, представляющих целевые данные: MedicalInsuranceDetails, CarInsuranceDetails, HouseInsuranceDetails, итд. У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц.
- и есть 1 сущность, которая представляет стандартные данные: ExistedInsuranceDetails

И вот мы подобрались к самому главному. А ExistedInsuranceDetails к InsuranceDetails как относится?
С одной стороны это 1:M, потому что один InsuranceDetails может иметь много ExistedInsuranceDetails.
C другой стороны, это 1:1, потому что один InsuranceDetails может иметь 0 или 1 ExistedInsuranceDetails, относящихся к разделу Medical, 0 или 1 ExistedInsuranceDetails относящихся к разделу Car итд.


Т.е. получается какая-то 1:M, но каждая связь тегированна уникально... в общем я даже не догадываюсь как это правильно погуглить 🙂

Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде. Есть сомнения в правильности такого подхода в целом, но тут на чаще весов "за", то что местный ORM такое переваривает очень хорошо и не требует дополнительных телодвижений, на чаще весов "против" - сомнения, что это всё вообще правильно.

Вопрос: есть какой-то "правильный" подход для решения подобного класса задач?

> У них явно связь 1:1 c InsuranceDetails, и на стороне InsuranceDetails просто лежит FK указывающий на PK каждой из этих таблиц. Где Вы такое нашли в реляционном проектировании? ;) Т.е. нормализация Вам бы такой структуры не дала. Т.е. это просто для удобства? > Сейчас решил это тем, что затащил вообще все FK в InsuranceDetails фактически гвоздями прибив 1:M везде. Вот и показали бы схему (\d каждой таблицы), а то как-то непонятно, IMHO...