KK
Вероятно вы не очень правильно разделили монолит на микросервисы, раз у вас получаются пересечения по данным.
Size: a a a
2020 September 28
SA
Далеко не всегда получается хорошо разделить, если продолжать думать в парадигме реляционных баз данных
РГ
ситуация звучит как микросервисы ради микросервисов
F
Тогда советую именно строить ERD и смотреть, как модели можно кластеровать по микросервисам. И как дробить какие-нибудь ненужные связи
er диаграмма есть. Но прикол в том что мы пока не знаем конечный вариант из за заминки аналитиков (
SA
Я очень советую подумать про нереляционную базу. Микросервисы нужны для внутреннего упрощения. Если вместо внутренней простоты вы получите необходимость делать тонны ручных джойнов, то ценности во всем начинании не будет.
Это как попытки похудеть, подсчитывая калории, но не изменяя образа жизни. Пару месяцев будет хорошо, а через полгода станет хуже, чем было до этого
Это как попытки похудеть, подсчитывая калории, но не изменяя образа жизни. Пару месяцев будет хорошо, а через полгода станет хуже, чем было до этого
KK
Почему же сразу не реляционную? Можно и на реляционной, просто не шарить одну базу между сервисами.
SA
Можно реляционную, но тогда психологически сложно менять уже существующую модель данных
SA
Если такой проблемы нет, то, конечно, гоу он, технически-то все ок
KK
С нереляционкой шаринг базы - это тоже не очень удачный вариант будет.
KK
ну от смены моделей мы не застрахованны на данном этапе, потому-что мы запросили возможность сокращения таблиц путём уменьшения количества сущностей в переноса полей в другие таблицы
Если сервисы общаются только через API, то им будет плевать на то что там меняется в моделях других сервисов - лишь бы API не менялся.
F
ну и да еще вариант есть что-бы много запросов не делать допустим есть таблица которая хранит какие-то словари наборы данных. В таблицах которые мы заполняем или обновляем хранить от таблицы словаря не конкретное значение ввиде uuid или значения определённого поля. А сразу json той записи которую выбрали
KK
ну и да еще вариант есть что-бы много запросов не делать допустим есть таблица которая хранит какие-то словари наборы данных. В таблицах которые мы заполняем или обновляем хранить от таблицы словаря не конкретное значение ввиде uuid или значения определённого поля. А сразу json той записи которую выбрали
Это вроде называется денормализация. Использовать её можно и часто так и делают для ускорения работы с базой. Но к этому надо подходить с умом. Не делать это везде подряд если очень важна консистентность. Например если при изменении "словаря" изменение должно сразу отразится на всех таблицах, которые связаны с этим словарём. Делать UPDATE денормализованной таблицы с килло-тонами записей - хреновый вариант.