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

Question

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

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

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

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

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

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

Answer 1

Лично я никогда не находил проки, достаточно гибкие для 'R' в CRUD. Я обычно использую представления. Но доступ к базе данных с помощью views & procs также позволяет абстрагировать таблицы базы данных, предоставляя модели данных большую гибкость в будущем ... почти как при работе с интерфейсом.

Answer 2

полностью зависит от вашей среды. Ответ на этот вопрос на самом деле не проблема кодирования, а бизнес-решение.

Если ваша база данных поддерживает только одно приложение и достаточно тесно интегрирована с ним, то из соображений гибкости лучше поместить свою логику в прикладную программу. В этих условиях обработка базы данных просто как простого хранилища данных с использованием общих функциональных возможностей немного теряет вас и повышает гибкость - с поставщиками, внедрением, развертыванием и многим другим.

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

1. С корпоративной базой данных актив является ценным, и неверные данные или действия могут иметь опасные для бизнеса последствия. В этих обстоятельствах вашей главной заботой является бизнес, а не то, насколько удобный доступ для ваших кодировщиков.
2. Такие базы данных по определению доступны более чем одному приложению. Вам необходимо использовать абстракцию, предлагаемую хранимыми процессами, чтобы база данных могла быть изменена при обновлении приложения A, и у вас нет ресурса для обновления приложения B.
3. Аналогичным образом, инкапсуляция бизнес-логики в SP, а не в коде приложения, позволяет вносить изменения в такую ​​логику в рамках бизнеса проще и надежнее, чем если бы такая логика была встроена в код приложения. Например, если расчет налога изменяется, он менее трудоемок и более надежен, если расчет необходимо изменить в одном SP, а не в нескольких приложениях. Основное правило здесь заключается в том, что бизнес-правило должно быть реализовано в самой близкой точке к данным, где оно уникально - поэтому, если у вас есть специализированное приложение, тогда логика для этого приложения может быть реализована в этом приложении, но логика более широко применима. чтобы бизнес был реализован в СП.

Answer 3

Эта статья блога представляет собой очень хороший контрапункт толпе "Хранимые прокы всегда лучше".

http://statestreetgang.net/post/2008/04/My-Statement-on-Stored-Procedures.aspx

Лично я нахожусь на заборе и склоняюсь к их использованию.

Answer 4

Использование хранимых процедур (и тех, которые не используют динамический SQL) позволяет пользователям базы данных настраивать производительность и, что более важно, ограничивает доступ к таблицам и представлениям базы данных, чтобы никто не мог изменить их, кроме dba. Это ОЧЕНЬ важно, если у вас есть финансовое заявление и вы хотите защитить себя от внутреннего мошенничества.

Answer 5

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

Есть и другие преимущества, такие как

1. Безопасность - если у вас нет прямого доступа к базовой таблице, это может быть частью подхода глубокой защиты.
2. Гибкость в вашем PDM - вы можете вносить масштабные изменения в ваш PDM по соображениям производительности, и до тех пор, пока вы сохраняете свои «контракты» (SP, Views), прикладной уровень не осознается.
3. Futureproofing - вы хорошо подготовлены для другого приложения, возможно написанного на другом языке, для доступа к вашей базе данных.

Лучше всего работает, когда у вас есть выделенная база данных, человек или команда.

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

Answer 6

Как уже отмечали другие, это очень сильно зависит от вашей среды.

Однако даже в корпоративной ситуации, когда вы хотите защитить критически важные данные, использование хранимых процедур для CRUD не обязательно является обязательным. Как уже отмечалось, использование хранимой процедуры для реализации вставки базы данных предполагает, что хранимая процедура будет умнее, чем разработчик приложений. Хранимые процедуры - это логика, поэтому умение их писать - это навыки программиста. Таким образом, если у вас есть администратор базы данных, который также является лучшим программистом, чем ваши программисты, то непременно заставьте их написать хранимые процедуры, чтобы ваши программисты были честными. Это может быть в некоторых местах. Следует иметь в виду, что Томас Хансен считает, что использование хранимых процедур может привести к тому, что вся организация будет привязана к логике данной хранимой процедуры. Опять же, некоторые организации могут хотеть или нуждаться в этом.

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

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

Если вы собираетесь добавлять большие объемы данных, полезны такие вещи, как командные файлы и отключение транзакций. Но, на мой взгляд, CRUD подразумевает не большие объемы создаваемых данных, а небольшие случаи создания, чтения, редактирования и удаления данных, как это делается в большинстве приложений уровня пользователя.

Answer 7

Да, особенно в Oracle.

В Oracle для триггеров и внешних ключей требуется много SQL/PLSQL переключений контекста.

Я лично разрабатываю базы данных, которые требуют больших CRUD операций следующим образом:

1. Я не использую ни триггеры, ни внешние ключи.
   • Пользователям не разрешено изменять таблицы.
   • Все DML в базе данных выполняются следующим образом:
     1. Данные для вставки / обновления / удаления загружаются в таблицу TEMP
   • Вызывается хранимая процедура, в которой:
     1. Данные проверяются на согласованность, как в BEFORE I/U/D триггерах и внешних ключах.
        • Данные MERGE находятся в таблице
        • Данные проверяются на согласованность, как в AFTER I/U/D триггерах и внешних ключах

В базе данных у меня есть служебная таблица, которая содержит эти foreign key -подобные отношения между полями.

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

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

Это огромное увеличение производительности модификации.

Если вам нужно UPDATE, скажем, 50,000 строк в таблице 10,000,000 строк, это может занять 10 секунд вместо 200 секунд или даже больше.

---

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

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

Answer 8

Чтобы использовать ваш список:

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

Другими словами, это зависит от вашего рабочего контекста.

Answer 9

Это в значительной степени зависит от ваших данных и вашей среды.

Если вы делаете свою базу данных широко доступной для разрозненных читателей и писателей, используйте SPROC: таким образом вы сохраняете абсолютный контроль.

Если вы находитесь в более закрытом магазине, где доверяете разработчикам, используйте LINQ. Это обеспечивает гораздо большую гибкость доступа к данным и позволяет легко вносить изменения в базу данных в будущем. (Например, если вы добавляете поле в таблицу, вам просто нужно сгенерировать частичные классы доступа к данным LINQ, и все готово; в противном случае вам придется переписать группу SPROC, а также изменить уровень доступа к данным в приложении .)

Answer 10

База данных представляет собой корзину , как только вы начнете рассматривать ее как часть своей бизнес-логики, вы окажетесь в очень узком и неудобном месте и создадите MUD вместо SW ...

Отдельная логика и данные. СП: логика ...!

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

ПП в 99,9% случаев используют шаблон АНТИ-дизайна ...!