Недостаток хранимых процедур

Question

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

Answer 1

Преимущества : Предоставляет «открытый интерфейс» для базы данных (еще один уровень абстракции).

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

Недостатки : Может быть, не лучшее место, чтобы поставить сложную логику. Однако, следуя идее, что сложная логика принадлежит коду приложения, а не к хранимым процедурам, хранимые процедуры становятся просто операциями CRUD (в каждой таблице есть процедуры «Создать», «Чтение», «Обновить» и «Удалить»). В этом случае хранимые процедуры не добавляют никакой ценности приложению, они только усложняют обслуживание и становятся ненужными.

Все запросы сгруппированы, поэтому сложнее увидеть контекст приложения, в котором они используются. Анализ влияния изменений длится дольше, а выполнение изменений также дольше.

Поэтому : использовать хранимые процедуры для инкапсуляции сложных запросов (сложные объединения, сложные выражения where, ...). Но не используйте хранимые процедуры для сложных приложений / доменов / бизнес-логики, и также не используйте хранимые процедуры для CRUD. Таким образом, хранимые процедуры должны использоваться в меньшинстве случаев, а не быть стандартным инструментом для всех запросов в приложении.

Группировать код (включая запросы) для достижения «функциональной сплоченности» вместо группировки по инструменту / технологии. Чтобы позволить администратору базы данных оптимизировать базу данных в зависимости от того, как она запрашивается, используйте профилировщик.

Answer 2

Исправление: от того, прекомпилированы ли они, зависит от базы данных. Например, в SQL Server это не так. Хранимые процедуры и параметризованный SQL компилируются перед запуском. Хранимая процедура может иногда использовать план выполнения, если соответствующий план существует ... но так же может параметризованный SQL.

Редактировать: Вот что MSDN говорит об этом :

SQL Server 2000 и SQL Server версии 7.0 включают ряд изменений в обработке операторов, которые распространяют многие преимущества производительности хранимых процедур на все операторы SQL. SQL Server 2000 и SQL Server 7.0 не сохраняют частично скомпилированный план для хранимых процедур при их создании. Хранимая процедура компилируется во время выполнения, как и любая другая инструкция Transact-SQL. SQL Server 2000 и SQL Server 7.0 сохраняют планы выполнения для всех операторов SQL в кэше процедур, а не только для планов выполнения хранимых процедур.

Answer 3

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

Answer 4

Недостатки

• Рефакторинг сложнее. Переименование или изменение места расположения хранимой процедуры может привести к плохому эффекту.

• Хранимая процедура модульного тестирования требует помощи кода вне БД

Преимущество

• Вам не нужно развертывать, чтобы внести изменения.
• Быстрее когда-нибудь
• Проще расширить систему

Answer 5

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

Недостаток: может сделать отладку более сложной. Может также быть чувствительным к удалению во время операций копирования, если не сделано правильно.

Answer 6

С текущими библиотеками .Net 3.5 framework я бы использовал Linq для выполнения большинства операций с базой данных. Там могут быть места, где SP имеет больше смысла. Но у Linq есть условия для запуска SP тоже.

По теме недостатков СП, ознакомьтесь со следующей ссылкой - интересный анализ. Проверьте также комментарии в блоге.

http://www.spoiledtechie.com/post/Whats-up-with-Stored-Procedures-these-days.aspx

Answer 7

Недостатки

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

Answer 8

Вероятно, хотите посмотреть здесь для обсуждения этой темы.

Answer 9

Другим недостатком является управление версиями, потому что некоторая бизнес-логика теперь находится на стороне базы данных. Можете ли вы легко откатиться на v1 (год назад) с v2 (сейчас)?

Возможное решение - создание версий имен хранимых процедур. Но теперь база данных - это путаница со старыми и новыми хранимыми процедурами.

Answer 10

Лишь несколько причин, по которым я использую хранимые процедуры исключительно при создании приложений:

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