кандидат на хранимую процедуру?

Question

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

Его не нужно запускать очень часто, поэтому нет необходимости подключать его к триггеру ... Я, вероятно, просто напишу скрипт php, чтобы запускать его с помощью ежечасного задания cron. (или, может быть, я могу запустить его через командную строку)

Итак, я лаю не на этом дереве? Спасибо, я приму любой полезный ответ.

 SELECT
  COUNT(*) AS thecount,
  MAX(datetime_acc) AS DATE,
  u.created_usr,
  @payout:=IF(u.created_usr < '2011-01-24',20,10) AS payout,
  level_usr,
  @uid_usr:=p.uid_usr,
  @affiliate:=u.affiliate_aff,
  created_usr,
  firstname_usr, 
  lastname_usr,
  contact_aff,
  c.id_com

FROM payment_acc p
 LEFT JOIN users_usr u ON p.uid_usr = u.id_usr 
 LEFT JOIN commissions_com c ON c.uid_usr = u.id_usr
 LEFT JOIN affiliate_aff a ON a.code_aff = u.affiliate_aff




WHERE p.type_acc = 'monthly payment'
AND affiliate_aff IS NOT NULL
GROUP BY p.uid_usr
HAVING thecount > 1

ORDER BY affiliate_aff

ВСТАВКА:

Insert into commissions_com 
    date_generated_com,
    amount_com,
    uid_usr, 
    code_aff, 
    status_com
values
   (NOW(),
    @payout,
    @uid_usr,
    @code_aff,
    'new')

Answer 1

Использование хранимых процедур является стратегическим решением;это не следует воспринимать легкомысленно.

Хранимые процедуры MySQL очень ограничены и имеют много недостатков:

• Язык очень слабый, особенно до 5.5, где нет чистого способавыдачи ошибки
• Некоторые вещи не могут быть выполнены без использования SQL, подготовленного внутри хранимой процедуры, что является невероятно неприятным шаблоном и очень подвержено ошибкам.
• Абсолютно категорически нет отладкисредства
• Они имеют только фиксированное количество обязательных позиционных параметров.Изменение интерфейса на процедуру обратно-совместимым способом обычно невозможно.Таким образом, в итоге вы получаете процедуру registerAccount, а также registerAccount2, registerAccount3 и т. Д., Потому что вам нужно было добавить дополнительные параметры позже, но вы не смогли мгновенно изменить весь код, вызывающий процедуры (поскольку, конечно, он распространяется на разные машины по всему вашемуинфраструктуры, и вам необходимо выполнить непрерывное обновление).
• Управление кодом / контроль изменений - наличие хранимых процедур добавляет дополнительный фрагмент кода для контроля (в разработке, в средах тестирования, на производстве и т. д.)

Для меня это все веские причины не использовать хранимые процедуры.Их трудно писать (язык слаб), вы должны писать код, который использует «плохие» шаблоны, и их трудно писать правильно (трудно отладить, трудно понять, что происходит внутри).

Также многие люди ссылаются на некоторые преимущества

• Безопасность - только выгода, если вы правильно используете свои хранимые процедуры и имеете продуманную модель безопасности во всем приложении
• Производительность - стратегическое решение, основанное на производительности, - это ОЧЕНЬ преждевременная оптимизация.В большинстве случаев специальный SQL работает так же, как и хранимые процедуры.Задержка нескольких операторов может быть уменьшена путем использования клиента, который поддерживает CLIENT_MULTI_STATEMENTS, и объединения нескольких запросов в одно сообщение запроса.
• Абстракция / повторное использование.К сожалению, крайняя сложность получения структурированных данных в / из процедур усложняет это.Это может быть полезно, если у вас действительно хорошо продуманная система.Часто проще написать подпрограммы на вашем языке интерфейса и использовать их вместо этого.Или используйте сервер приложений, который позволяет более богатый интерфейс.

Answer 2

Какое "значение" вы ищете?

Джефф Этвуд долгое время ставил под сомнение использование хранимых процедур.

Из документации mysql :

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

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

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

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