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

Question

Если вы используете php5 и mysql5, есть ли существенное преимущество использования хранимых процедур над подготовленными операторами? (я где-то читал, что вы не можете получить существенный прирост производительности от хранимой процедуры mysql5)

Answer 1

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

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

Answer 2

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

1. Хотите, чтобы ваш инженер баз данных оптимизировал запросы для повышения производительности
2. Хотите абстрагировать сложность запросов от простых API
3. ХОЧУ, чтобы ваша логика распространялась, потому что часть того, что происходит в базе данных, может быть интеллектуальной собственностью, которую вы не хотите раскрывать другим сторонам
4. ХОТИТЕ, чтобы ваша логика была распределена, потому что такова природа распределенных n-уровневых вычислений
5. может потребоваться, чтобы инженер базы данных или администратор БД изменили схему без изменения кода приложения (хранимые процедуры, благодаря предоставлению API, обеспечивают уровень абстракции)

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Хотя я предпочитаю придерживаться SQL с точки зрения управления / развертывания кода и модульного тестирования.