ОРМ прекрасно справляется с запросами когда их не более (скажем) одного в секунду из несложного джойна не более чем пяти-шести таблиц. А попробуйте добится быстрого отклика от БД когда размеры таблиц 10М записей и идут одновременно 10К запросов в секунду к джойнам многих таблиц. И одновременно идут инсерты и апдейты в ети таблицы. Без оптимизации на уровне БД делать нечего, на уровне ОРМ етого не добиться.
Микросервисы — это когда каждая часть системы живёт отдельно, со своей БД, своей логикой, своей жизнью.
Пример: ты пишешь бэкенд для интернет-магазина, и в одном проекте у тебя и пользователи, и товары, и корзина, и админка.
Я похоже отстал от веб-разработки (10 лет сижу только в базах данных), но неужели каждый микросервис юзает СВОЮ бд? В вашем примере интернет-магазина разве будет не одна общая база? Неужели отдел продаж имеет свой список покупок, отдел бухгалтерии - свой список платежей, а пользователи - свой? А как же их синхронизировать? А если отмена платежа? И главное - зачем дублировать? Я бы спроектировал одну базу на все отделы интернет-магазина. В чем я не прав?
ОРМ прекрасно справляется с запросами когда их не более (скажем) одного в секунду из несложного джойна не более чем пяти-шести таблиц. А попробуйте добится быстрого отклика от БД когда размеры таблиц 10М записей и идут одновременно 10К запросов в секунду к джойнам многих таблиц. И одновременно идут инсерты и апдейты в ети таблицы. Без оптимизации на уровне БД делать нечего, на уровне ОРМ етого не добиться.
Я похоже отстал от веб-разработки (10 лет сижу только в базах данных), но неужели каждый микросервис юзает СВОЮ бд? В вашем примере интернет-магазина разве будет не одна общая база? Неужели отдел продаж имеет свой список покупок, отдел бухгалтерии - свой список платежей, а пользователи - свой?
А как же их синхронизировать? А если отмена платежа? И главное - зачем дублировать?
Я бы спроектировал одну базу на все отделы интернет-магазина.
В чем я не прав?