Должен ли я использовать триггер базы данных для следующей проблемы?

Question

Мне было дано следующее задание:

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

Похоже ли это на ситуацию, когда триггер базы данных можно эффективно использовать или лучше создать внешнее приложение (возможно, службу Windows), которое проверяет базу данных каждые 5 минут и выполняет необходимые обновления?

Обновление:

Это не обязательно должно быть мгновенным, поэтому, если бы я использовал службу Windows или планировщик задач, он, вероятно, был бы установлен с интервалом в 5 минут.Практически мгновенно использование триггера - это просто бонус от использования триггера, а не решающий фактор.

Моя главная проблема в том, является ли это правильным способом использования триггера?Следует ли использовать триггеры для копирования данных или это плохая практика?Также могут возникнуть проблемы с использованием триггера, например, при сбое копирования может ли он заблокировать таблицу, останавливая копирование последующих строк?Если одна копия занимает слишком много времени, не будет ли она обрабатывать строки, которые были вставлены, пока она была шиной?Если я не использую триггер, есть ли лучшее решение, например, служба Windows или консольное приложение, использующее Windows Schedular?

Спасибо

Answer 1

Вы можете сделать это с помощью SQL Job. Напишите хранимую процедуру для копирования данных и ввода в график работы. Эта работа будет выполняться через каждые 5 минут.

step_by_step_guide_to_add_a_sql_job_in_sql_server_2005

sql_server_agent_jobs

Answer 2

Я согласен с Мухаммедом. Это должно быть сделано с помощью задания базы данных.

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

Также в ситуации, когда в таблицу A вставлена ​​строка, для которой ключ не существует, эта строка остается в таблице A. Это означает, что ваш триггер должен быть на уровне таблицы, а не на уровне строки.

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

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

Answer 3

Триггеры заманивают вас как простое исправление, но вскоре вы тратите больше времени на отладку триггеров, чем на чтение StackOverflow. Триггеры злые. Держись от них подальше.

Answer 4

Пока логика проста, я бы сказал, что нужно идти вперед и использовать триггер. Проблемы начинают возникать, когда триггеры реализуют сложную логику, но если это просто «Убедитесь, что данные существуют в таблице поиска, и если они действительно копируют данные из A в B и удаляют из A».

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

Делись и наслаждайся.

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

Это звучит как очень простая операция. Если это так, и удаление строки из таблицы A и вставка ее в таблицу B не займет много времени, я бы выбрал триггер. Преимущество заключается в том, что данные всегда актуальны, а не регулярно синхронизируются.

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