Если вы используете php5 и mysql5, существует ли существенное преимущество в использовании хранимых procs над подготовленными операторами? (я читал где-то, что вы не можете получить существенную прибыль от хранимой процедуры mysql5)
На самом деле это не одно и то же – с хранимыми процедурами, логика базы данных находится внутри базы данных. Подготовленные заявления в основном избегают повторного разбора запросов, если они вызываются несколько раз – преимущество в производительности может сильно различаться.
Выбор использовать тот или иной действительно зависит от вашей конкретной ситуации. Я больше не использую хранимые procs, поскольку мне нравится иметь всю мою логику в одном месте.
Хранимые процедуры имеют смысл для приложений профессионального уровня (IE), где вы:
Есть и другие причины.
Подготовленные заявления лучше для работы, выполненной в течение сеанса. Но если вы потратите время на создание подготовленного заявления, вы по существу сделали все необходимое для создания хранимой процедуры. Разница заключается в том, что хранимая процедура доступна на нескольких сеансах (при условии наличия GRANTS в базе данных).
Что я не могу понять, так это то, что если у вас есть опция для хранимого proc или подготовленного оператора, почему вы будете беспокоиться о подготовленных операторах. Большинство обсуждений в области SP и PS, похоже, сосредоточены на различиях между ними, а не на том, почему использовать один против другого. Это всегда сводится к тому, что «зависит от того, что вы пытаетесь сделать». Но я не видел хорошо организованного описания: используйте proc, если вам нужно VS использовать инструкцию, если вам нужно ….
Некоторые преимущества хранимых процедур:
Некоторые недостатки хранимых процедур:
Я не думаю, что для этого вопроса существует один обобщенный ответ, потому что в зависимости от ситуации есть плюсы и минусы. Если вы следуете принципам, таким как простота, СУХИЕ, тестирование и избегаете преждевременной оптимизации, вы, скорее всего, окажетесь в порядке.
Возможно, это не так или стоит упомянуть здесь, но хранимые процедуры также являются «переносимыми» в случае, если они являются агностиками. Вы можете вызывать одни и те же хранимые процедуры в своей базе данных изнутри, скажем, Java, как с PHP. Поскольку процедуры находятся в базе данных, все, что имеет доступ к базе данных, может запросить их одинаково.
Существенное преимущество хранимых процедур заключается в том, что ваши данные не пересекают слой (в данном случае это будет слой PHP / MySQL), прежде чем к нему может быть применена логика. В некоторых запросах может потребоваться несколько операторов select, которые медленнее выполняются через PHP, чем в MySQL.
Теперь, как указывает пробиед , хорошо иметь всю логику в одном месте. Но я работал над проектами, где было просто нереалистично запрашивать требуемые данные с помощью PHP; это должно быть сделано с помощью хранимой процедуры.
Начну с того, что мне не нравится идея хранимых процедур, я скорее иду на подготовленный маршрут инструкций. В этом конкретном случае я думаю, что вы также сравниваете яблоки с апельсинами … они оба там, чтобы полностью заполнить разные функции ….
Я буду рассматривать только хранимую процедуру, если приложение основано только на базе 95% базы данных, тогда имеет смысл иметь некоторую логику в db.
Не знакомы с php, но в целом хранимые процедуры уже «скомпилированы», поэтому могут иметь незначительно более высокую производительность по SQL-заявлению.
Хотя мое предпочтение обычно связано с SQL с точки зрения управления / развертывания кода и тестирования модулей.