Для базы данных рекомендуется, чтобы приложения всегда выполняли операции CRUD через SP?

Question

Я слышал причины этого, и мне было любопытно, считают ли другие это лучшей практикой / хорошей идеей.

Одна из причин заключается в том, что введение ограничений на прямой доступ к таблицам базы данных и принуждение приложений / пользователей использовать SP (хранимые процедуры) для выполнения операций CRUD позволит администраторам баз данных

1. мелкозернистый контроль для утверждения / проверки ПС до их перевода в производство
2. избегайте случайных запросов, написанных разработчиками, которые могут вызвать нагрузку на сервер / другие проблемы с сервером

Это означает, что разработчик не может писать запросы Linq для таблиц (хотя возможны запросы Linq с участием SP) Это также означает, что разработчик должен забыть о проверках во время компиляции, а также о полном контроле над данными, а в основном использовать другой язык (SQL) для работы с данными.

Я не возражаю против этого, и не думаю, что это отличная идея. Мне просто любопытно узнать, что думают другие. Какие есть другие преимущества и недостатки этого подхода.

Обновление : Как упомянул Томас в своем ответе , я склонен думать, что SP - это логика, и использование «программирования баз данных в SQL» для выполнения логики хорошо, пока не «бизнес логика». Бизнес-логика нуждается в разделении, проверке во время компиляции и контрольных точках интеграции, а что нет.

Answer 1

Ну, еще одно очевидное преимущество - это производительность: после компиляции SP они будут выполняться быстрее, чем SQL в коде. Вы уже заявили об основных преимуществах SP для крупных организаций, которые следят за безопасностью и контролем. Это позволяет вашему администратору БД следить за SQL, работающим с БД, во время проблем с производительностью, также как и все это в БД.

Одним из недостатков является переносимость: если вы пишете коммерческое приложение, а заказчик настаивает на том, чтобы вы адаптировались к существующей БД, у вас будет немного больше работы с SP, чем со встроенным SQL.

Answer 2

Похоже, вы не доверяете разработчикам в написании хороших запросов.

Это, вероятно, из опыта.

Я бы предположил, что если плохие разработчики пишут дерьмовый код SQL, они также пишут плохой код приложения, а это означает, что управление делает плохую работу.

Проблема не в динамическом SQL (даже если он параметризован) в сравнении с хранимыми процедурами, а в плохом управлении.

Это не будет решено принудительным доступом к базе данных через хранимые процедуры.

В любом случае, даже если доступ к БД обеспечивается только с помощью хранимых процедур, плохие кодеры все равно будут способны нагрузить базу данных.

Реальность такова, что если вы затрудняете доступ к данным в базе данных, разработчики будут использовать другие методы, чтобы не помещать данные в базу данных или извращать базу данных. Например, скажем, у вас есть поле блога для хранения PDF-файлов или чего-то еще, что мешает им сериализовать объекты и сохранять их в BLOB-объектах, чтобы их можно было извлечь и десериализовать в коде?

Я был бы осторожен с этим.

Убедитесь, что хранимые процедуры попадают в систему контроля версий, и что развертывание хранимых процедур в соответствующей среде базы данных может выполняться автоматически инструментом построения (непрерывно или ежедневно) ...