@allogolden

Как организовать БД, если данные нужно отправлять по разным АПИ, в запросах которых поля отличаются?

Добрый день. Проектирую биллинг для создания и оплаты страховых полисов. В этом деле новичок, гуглил, не нашел нужную инфу.

Есть наш платежный шлюз, который умеет только доставлять деньги мерчанту по его айди. Ему мы отдаем только сумму и мерчант айди, он делает деньги туда-сюда.

Есть биллинг страховых (у нас есть АПИ пока только одной), который требует определенные поля для создания страхового полиса.

Есть биллинг, который делаем мы, чтобы все эти полисы хранить, создавать, отдавать на оплату, отслеживать статусы и т.д.

Проблема: мы не знаем насколько разные будут поля, требующиеся для создания полисов у разных страховых. Кроме разницы страховых, есть разница в типе страховки (и они от компании к компании тоже отличаются).

Разраб предложил создать отдельную таблицу для страховой компании и этого типа услуги, в которой будут "неуниверсальные" поля этой страховой (и конкретной услуги).
* Первичную организацию БД, которую я набросал, прикрепляю картинкой.
65c365153111f244998067.png

То есть теперь получается, что для каждой пары услуга-компания нужно делать отдельную таблицу, что не есть хорошо.
Есть ли более оптимальное решение задачи? Может книжку какую почитать?

Если есть вопросы по проекту - с радостью отвечу. Если нужно будет - скину описание проекта.

Update:
Директор отказался от идеи NoSQL, поэтому пришлось выкручиваться. Придумал такую структуру:
65c5f56e4e197279474473.png
Разрабы кивнули, пусть записям придется ссылаться на записи из той же таблицы.
Будут вопросы - отвечу.
  • Вопрос задан
  • 109 просмотров
Решения вопроса 2
vabka
@vabka
Токсичный шарпист
Если не упарываться в NoSQL, то можно классическим реляционным подходом - EAV-паттерн применить.
Если постгрес, то можно его в документ-ориентированную базу превратить, благодаря jsonb полям.

Я бы ввёл две таблицы:
1. "Описание услуги" - с перечислением всех полей, которые должны быть указаны в заявке. (чтобы можно было сформировать форму)
2. "Заявка" - там все специфичные поля записываются в jsonb-колонку.

GraphQL позволит гибко настраивать payload для внешних API

Мне кажется, что в этом случае GraphQL не очень подходит, так как у контрагентов может быть свой интерфейс взаимодействия => всё равно в коде нужно будет реализовать коннектор для каждого.
Ответ написан
@allogolden Автор вопроса
Решил сам, в описании - как.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
newross
@newross
Product owner
В таких случаях хорошо сработает связка из NoSQL + GraphQL.
NoSQL даст возможность использовать одну и туже коллекцию для всех страховых, то есть сможете легко строить аналитику без 100500 join
GraphQL позволит гибко настраивать payload для внешних API
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы