Когда использовать хранимые процедуры и триггеры против аппликативного слоя

Question

У меня есть дилемма, на которой я надеюсь, что у вас будут мнения экспертов.

У меня есть таблица под названием CARDS с колонкой STATUS. Если статус записи изменяется с «загрузки» на «публикацию», я должен вставить ссылку на запись в другую таблицу под названием CARD_ASSIGNMENTS. Кроме того, запись должна быть добавлена ​​в CARD_ASSIGNMENTS столько раз, сколько активных записей в СКАНЕРЕ.

Другими словами, если есть два активных сканеров, я в конечном итоге с двумя записями в CARD_ASSIGNMENTS, как показано ниже:

ID CARD_ID SCANNER_ID STATUS_ID 
1 1   1   4 
2 1   2   4 

Моя дилемма в том, что я не совсем уверен, что будет наиболее эффективным способ выполнить вышеуказанное. Я рассмотрел следующие варианты:

1. От PHP - Сделайте один запрос UPDATE, а затем запрос INSERT.
2. Создайте хранимую процедуру, которая позаботится об обновлении записи CARDS и добавлении записей в CARD_ASSIGNMENTS. Затем просто вызовите эту хранимую процедуру из PHP.
3. Создайте триггер ON UPDATE для таблицы CARDS, которая будет обрабатывать INSERTS в таблице CARD_ASSIGNMENTS.

PS. Упрощенная версия моей базы данных доступна на MySQL Fiddle

Спасибо,
Кейт

Answer 1

Интересный вопрос.

Я расскажу вам, как подойти к проблеме.

Таким образом, вы должны начать с определения именно три вещи:

1. ожидаемая функциональность
2. политики доступа к функциональности
3. технической политики обновления

Здесь I» Подробные данные.

Итак, первое, что вы должны определить свою функциональность. Поступая таким образом, вы сможете узнать, не означает ли добавление карты всегда во всех возможных парадигмах (извините за педантичное слово, которое я не могу найти более правильным) вашей информационной системы, что эта карта MUST существуют в другой таблице в соответствии с вашими спецификациями. Эта функциональная ссылка 1-1 должна быть указана TRUE или FALSE. Это действительно важно. Сказанное другими словами, если есть хотя бы одна возможность, что в один прекрасный день вы не захотите копировать эту запись в другую таблицу, это означает, что триггер является неправильным решением или, по крайней мере, его следует учитывать в аварийном режиме (например, переменная внутри, которая позволяет ему не выполняться в некоторых условиях).

Затем идет вторая точка, о политике доступа. Вы должны знать, будут ли разрешенные системы доступа делать это, используя ваш прикладной уровень или если они могут разработать свой собственный (стиль SAAS).Если это так, ваш php-слой будет бесполезен, а хранимая процедура - отличный вариант, поскольку каждый технический и бизнес-уровень будет проходить через него да или да.

Последнее, что нужно знать о том, сможете ли вы обновить свой php-слой за один день. В большинстве случаев ответ «да». Если это так, возможно, вам придется изменить часть, содержащую эту логику sql, о которой вы говорите. Тогда, имея все в хранимой процедуре и сохраняя ее жестко закодированную в php, определенно сэкономит ваше время и улучшит стабильность.

---

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

Преимущества заключаются в следующем:

• нет или меньше рисков прерывания интернет-процесса, так как вы уменьшаете количество операций
• разные графики для alliviate загрузки базы данных
• более безопасной политики, поскольку для выполнения хранимой процедуры требуется только один грант, в то время как использование одного и того же sql с php потребует вложений для вставки/обновления
• лучшее качество ведения журнала: вы можете иметь журнал на каждое задание
• лучший аварийный ответ: при неудачном выполнении задания (если он хорошо продуман) вы можете перезапустить его, и все.

Долгий пост, но это было интересно, и я действительно хотел поделиться этими идеями.

Cheers!

Answer 2

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