Можно
Если это микросервисы как бы, то общая база - это антипаттерн
почему? изобретать acid проще?
Потому что: 1. Так пишут в книгах по микросервисной архитектуре 2. Когда один сервис меняет что-то в базе и накатывает миграцию, второй об этом может ничего не знать - и ляжет
Мы миграции и модели вытащили в отдельную репу. И накатываем через npm пакеты. Все счастливы
1. я думаю там вряд ли пишут о серебряной пуле. 2. для этого есть dba, review вот это все, и в одном сервисе можно упасть при желании.
бизнес логика все равно сломается
Какие модели? Бывают же сырые запросы, внутри которых могут использоваться таблицы, которых в реальности уже нет, например
Если в проекте 20+ микросервисов, всё в одной базе держать? Зачем? И кому это удобно? Я просто имею несколько проектов с общей базой, и это такое себе весьма
мне нужно на стороне от тг бота, обновлять базу раз в день, я питаюсь сделать это отдельным файлом и функцией от самого бота, правильно ли это?
я такого не говорил, вы сами за меня придумали тезис, сами опровергли. отлично, продолжайте в том же духе.
Ну может быть, окей)
От сырых запросов конечно не спасет. Тут или по орм или ...
как именно обновлять?
Просто в любом моем проекте, который использует ORM, есть так или иначе и сырые запросы
вопрос на самом деле способны ли команды микросервисов договариваться, что в базе есть "апи", а что есть "особенности имплементации"
Сделайте API (Rest или grpc) для обмена информацией между сервисами. А базы пусть разные будут.
Записывать новые строки в базу
Обсуждают сегодня