Хороший способ уменьшить масштабируемость вашего уровня данных - это взаимодействовать с ним на процедурной основе. (Выбрать строку..процесс ... обновить строку, повторить)
Это можно сделать в хранимой процедуре с помощью курсоров или в приложении (извлечь строку, обработать, обновить строку). Результат (низкая производительность) тот же.
Когда люди говорят, что хотят выполнить обработку в своем приложении, это иногда подразумевает процедурное взаимодействие.
Иногда бывает необходимо обрабатывать данные процедурно, однако, по моему опыту, разработчики с ограниченным опытом работы с базами данных будут стремиться проектировать системы таким образом, чтобы не использовать прочность платформы, потому что им неудобно думать с точки зрения решений на основе множеств. Это может привести к серьезным проблемам с производительностью.
Например, чтобы добавить 1 в поле подсчета всех строк в таблице, все, что нужно, это следующее:
UPDATE table SET cnt = cnt + 1
Процедурная обработка того же самого, вероятно, будет на несколько порядков медленнее при выполнении, и разработчики могут легко пропустить проблемы параллелизма, которые делают их процесс несостоятельным. Например, этот вид кода не является устойчивым, учитывая доступные уровни изоляции чтения многих платформ RDMBS.
SELECT id,cnt FROM table
...
foreach row
...
UPDATE table SET cnt = row.cnt+1 WHERE id=row.id
...
Я думаю, что с точки зрения абстракции и простоты обслуживания работающей среды использование хранимых процедур может быть полезным инструментом.
Кэш плана процедур и сокращение числа обращений к сети в средах с высокой задержкой также могут иметь значительные преимущества в производительности.
Верно и то, что попытка быть слишком умной или работать с очень сложными проблемами на полуиспеченном процедурном языке СУБД может легко стать рецептом катастрофы.