другой способ вместо триггера

Question

как я могу получить тип автоматических действий (аналогично тому, как они выполнялись триггерами), используя вместо этого хранимые процедуры или любым другим способом, потому что мне нужно, когда я (вставка или обновление или удаление) записи в таблице A или TableB мне нужно сделать ту же операцию в таблице C,

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

• Легко просматривать связи таблиц, ограничения, индексы, хранимые процедуры в базе данных, но триггеры трудно просматривать.
• Триггеры выполняются невидимыми для приложения-клиента. Они не видны или могут быть отслежены в коде отладки.
• Трудно следовать их логике, так как они могут быть запущены до или после вставки / обновления базы данных.
• Легко забыть о триггерах, и если нет документации, новым разработчикам будет сложно выяснить их существование.
• Триггеры запускаются каждый раз, когда поля базы данных обновляются, и это накладные расходы в системе. Это замедляет работу системы

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

Answer 1

Непосредственно не отвечая на ваш вопрос, но обращаясь к некоторым из упомянутых вами вещей:

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

Триггеры так же легко просматривать, как и хранимые процедуры.

Триггеры выполняются невидимыми для клиент-приложение. Oни не видны или могут быть прослежены в код отладки.

True. Но во многих случаях не просто войти в хранимую процедуру.

Трудно следовать их логике они могут быть уволены до или после происходит вставка / обновление базы данных.

Неправда. Триггеры срабатывают точно в то время, когда они определены как стрельба ДО или ВМЕСТО.

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

Неверно, если вы используете контроль версий.

Триггеры запускаются каждый раз, когда поля базы данных обновляются, и это накладные расходы на систему. Это делает систему беги медленнее

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

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

Answer 2

спасибо всем за быстрый ответ ,,,

Я понимаю, что использование триггера - хороший вариант, но я подумал, что если:

Я создал функцию (вставка / обновление / удаление) в tableC, и эту функцию можно вызывать из любой хранимой процедуры, которая будет (вставлять / обновлять / удалять) tableA и tableB. Это позволило бы мне управлять одной функцией, если требуется изменение, вместо изменения кода в каждой хранимой процедуре. Кроме того, я могу использовать транзакцию в каждой хранимой процедуре для обеспечения согласованности данных во всех таблицах.

Answer 3

Вам необходимо отозвать разрешения DML для A и B от пользователей и предоставить разрешение только на выполнение хранимой процедуры, которая обрабатывает вставки в C.

Answer 4

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

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

Это требует, чтобы весь код проходил через эту общую точку. Если нет, вы должны быть уверены, что везде, когда вставка выполняется в tableA, она повторяется в tableC. Это может быть намного больше работы.

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