Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, white_znake, Вы писали:

_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?


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

А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, white_znake, Вы писали:

_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?


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

А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model.
Но это сложно сделать, потому что встают вопросы согласования моделей. А архитектура приложения под это не заточено.