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

Ответ 1

Исправление: будут ли они предварительно скомпилированы, зависит от базы данных. Например, в 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 в кэше процедур, а не только планы выполнения хранимых процедур.

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

Недостатки

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

• Тестирование хранимой процедуры модуля требует помощи кода вне БД

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

• Вам не нужно развертывать, чтобы внести изменения.
• Быстрее
• Легче развернуть систему

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Недостатки

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

Преимущество: команда операций имеет крючок для контроля или устранения проблем в производстве.

Ответ 15

Преимущества: SP используются для извлечения множества операторов sql. Недостатки: отладка сложна.

Ответ 16

Еще одно преимущество может быть в крупных корпоративных средах, где у вас может быть несколько клиентских приложений и сред (например, веб-приложений, настольных компьютеров и инструментов для распространения на разных ОС), которые используют базу данных. Для некоторых бизнес-правил изменения могут быть внесены в базу данных, и это будет эффективно во всех средах.

Ответ 17

Преимущества -

• Организован в одном месте (не посыпается по всему коду)
• Гораздо быстрее, чем динамические запросы

Ответ 18

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

Ответ 19

простой ответ будет следующим: adv: это самая мощная структура для инкапсуляции T-SQL-кодов.    он не ограничен SELECT и поддерживает все коды DML.    он обеспечивает получение входных данных и непосредственное возвращение выходов.

dis: невозможно вызвать его в SELECT, поэтому вы не можете запустить его для    несколько записей.

Ответ 20

-Advantages хранимой процедуры

• Многоразовый и прозрачный для любого приложения.
• Secure.
• Сократите трафик данных между приложением и сервером базы данных.
• Повысить производительность приложения.

-Disadvantages Хранимой процедуры.

• Большое количество логических операций увеличивает загрузку процессора.
• Сложно отлаживать.
• Нелегко разрабатывать и поддерживать.
• Не предназначен для разработки сложной или гибкой бизнес-логики.