Подготовленное выражение против хранимой процедуры

Ответ 1

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

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

Ответ 2

Хранимые процедуры имеют смысл для приложений профессионального уровня (IE enterprise-grade), где вы:

• Хотите, чтобы ваш инженер базы данных оптимизировал запросы для производительности.
• Хотите абстрагироваться от сложности запросов к простым API
• ХОТИТЕ вашу логику распределить, потому что некоторые из того, что происходит в базе данных, могут быть интеллектуальной собственностью, которую вы не хотите показывать другим сторонам.
• ХОТИТЕ вашу логику распределить, потому что это характер распределенных, n-уровневых вычислений.
• вам может потребоваться, чтобы инженер базы данных или администратор баз данных изменил схему без изменения кода приложения (хранимые procs, благодаря предоставлению API, предоставляют слой абстракции).

Есть и другие причины.

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

Что я не могу понять, так это то, что если у вас есть опция для хранимой процедуры proc или prep, почему вы будете беспокоиться о подготовленных операторах. Большинство обсуждений в области SP и PS, похоже, сосредоточены на различиях между ними, а не на том, почему использовать один против другого. Это всегда сводится к тому, что "зависит от того, что вы пытаетесь сделать". Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS использовать инструкцию, если вам нужно....

Ответ 3

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

• Перенос между языками
• Возможно, упрощенный интерфейс, а иногда и повышение производительности для сложные запросы и особенно многопроцессорные запросы транзакции (тест!)
• Выставляя интерфейс, а не таблицы, могут быть использованы для улучшения безопасности и целостности

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

• Вводит бизнес-логику в базу данных - усложняет дизайн, дополнительное место для отслеживания контроль версий и устранение неполадок
• Потери производительности в некоторых ситуации (тест!)
• Менее переносимый между базами данных

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Я рассмотрю только хранимую процедуру, если приложение управляется только базой данных на 95%, тогда имеет смысл иметь некоторую логику в db.

Ответ 7

Не знакомы с php, но в целом хранимые процедуры уже "скомпилированы", поэтому могут иметь незначительную более высокую производительность над оператором sql.

Хотя мои предпочтения обычно связаны с SQL с точки зрения управления/развертывания кода и тестирования модулей.