точных познаний по проектированию баз данных.
Собственно, кейс такой.
Проектируется кусок 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...
Обсуждают сегодня