Безопасность - еще одно преимущество использования хранимых процедур. Вам не нужно устанавливать безопасность на уровне таблицы, если вы не используете динамический код (включая его хранимый процесс). Это означает, что ваши пользователи не могут ничего делать, если у них нет процедуры для этого. Это один из способов снижения вероятности мошенничества.
Дальнейшие процедуры проще настраивать на производительность, чем большинство кода приложения, и даже лучше, когда нужно что-то изменить - это все, что нужно запустить в производство, а не перекомпилировать все приложение.
Целостность данных должна поддерживаться на уровне базы данных. Это означает ограничения, значения по умолчанию, внешние ключи, возможно, триггеры (если у вас очень сложные правила или правила, включающие несколько таблиц). Если вы не сделаете этого на уровне базы данных, у вас в конечном итоге возникнут проблемы с целостностью. Peolpe напишет быстрое решение проблемы и запустит код в окне запроса, и необходимые правила будут пропущены, создав большую проблему. Миллино новых записей необходимо будет импортировать через программу ETL, которая не имеет доступа к приложению, потому что выполнение кода приложения потребует слишком много времени для запуска одной записи за раз.
Если вы думаете, что разрабатываете приложение, в котором проблема масштабируемости, вам нужно нанять специалиста по базам данных и следовать его или ее предложениям по проектированию на основе производительности. Базы данных могут масштабироваться до терабайт данных, но только в том случае, если они изначально разработаны кем-то, специализирующимся в таких вещах. Когда вы ждете, пока приложение будет работать медленнее, чем грязь, и у вас появится новый большой клиент, это слишком поздно. Проектирование базы данных должно учитывать производительность с самого начала, так как очень сложно перепроектировать, когда у вас уже есть миллионы записей.