An answer to this question утверждает, что «в идеале вы не позволили бы ad hoc DML создавать свои таблицы и управлять всеми DML с помощью хранимых процедур».Зачем использовать хранимые процедуры для выполнения операций INSERT, UPDATE и DELETE?
Почему этот идеал? Какая проблема заключается в решении по сравнению с GRANTing SELECT, UPDATE, INSERT, DELETE для таблиц, которые пользователь должен манипулировать?
Я бы поверила, что это следует общей идее о том, что действия должны определять допустимый ввод и возвращать ожидаемый результат. Идея специальных изменений структуры данных или базы данных представляет собой риск на нескольких уровнях, но может потребоваться на основе того, что требуется.
zerkms отметил в комментариях: нет абсолютов, только лучшие практики. Как наилучшая практика, если вы можете правильно охватить предполагаемые результаты и ограничить пользователей и процессы только необходимыми действиями и разрешениями, вы должны обеспечить безопасность и целостность системы.
Представления и хранимые процедуры похожи на API. Они позволяют скрыть реализацию, изменения версии, обеспечить безопасность и предотвратить неудачные операции с клиентом, такие как «получить все поля из всех счетов-фактур с момента начала работы компании».
Представления и хранимые процедуры позволяют администратору базы данных изменять схему для удовлетворения требований к производительности без нарушения приложений. Возможно, данные должны быть разделены горизонтально или вертикально, разбиты на файлы, могут быть добавлены или удалены поля и т. Д. Без хранимых процедур эти изменения потребуют значительных изменений приложений.
Контролируя хранимые процедуры и представления, используемые каждым приложением, вы можете обеспечить управление версиями изменений схемы - каждое приложение увидит API базы данных, который он ожидает.
Разрешения также могут быть назначены для определенных хранимых процедур, что позволяет ограничить возможности пользователей, не предоставляя им полный доступ к таблице. Например, вы можете разрешить постоянным сотрудникам изменять только свои контактные данные в таблице сотрудников, но позволить HR сделать более радикальные изменения.
Кроме того, вы можете инкапсулировать сложные операции с интенсивным использованием данных в рамках одной проверяемой процедуры, вместо того, чтобы управлять строками строки SQL SQL в исходном коде клиента.
Выполнение хранимой процедуры также можно легко отслеживать с помощью SQL Server Profiler или с динамическими представлениями управления. Это позволяет администратору баз данных находить горячие точки и виновников для возможного ухудшения производительности.
Это хорошо сказано и демонстрирует полное незнание элемента, называемого «деньги». Поскольку этот подход также в значительной степени заставляет MOVO большой бюджет развития в разработку. Очевидно, что это не проблема для некоторых, но гибкость и время выхода на рынок и деньги за функцию играют большую роль в большинстве предприятий. – TomTom
@TomTom Я думаю, что обратное верно. Стоимость переписывания приложения может быть настолько большой, что небольшие команды боятся исправить плохие схемы, предпочитая скрыть проблемы до тех пор, пока они не будут вынуждены их исправлять (как правило, путем краха). В результате бюджет тратится впустую на проблемы поддержки, а не на создание нового кода и функций. Жизнь проекта (и издержки и бюджет) не заканчивается, когда CD сжигается –
Есть несколько твердых причин, почему вы должны использовать хранимую процедуру
Хранимых процедуры компилируются один раз и хранятся в исполняемой форме, поэтому вызовы процедуры быстро и эффективны. Исполняемый код автоматически кэшируется и распределяется между пользователями.
Сохраненная процедура позволяет избежать SQL-инъекций.
Набор запросов в хранимой процедуре выполняется с одним вызовом. Это минимизирует использование медленных сетей, снижает сетевой трафик и улучшает время отклика в оба конца (например, в случае объемных вставок).
Это не «идеально» даже близко. В развитии нет абсолютов. – zerkms
Противоположность ad-hoc DML не обязательно означает хранимые процедуры. – DavidG
Сохраненные процедуры могут быть протестированы отдельно от кода. Их можно оптимизировать с помощью кэшированных планов, что приведет к более быстрому выполнению. Они параметризованы по умолчанию, защищая вас от SQL-инъекции. В случае необходимости они могут ссылаться на другой код в вашей базе данных. Изменения в хранимых процедурах не требуют перекомпиляции кода ... – Tanner