Триггер или SP: что мне использовать в моем случае? - PullRequest
Новая
       32

Триггер или SP: что мне использовать в моем случае?

4 голосов
/ 15 февраля 2011

У меня есть заявление, написанное другой командой в нашей компании, которое вставляет данные в одну таблицу. Допустим, они записывают данные в таблицу Log1 с полями:

  • Id (автоматически сгенерированный первичный ключ);
  • KeyId;
  • Значение1;
  • Значение2; * +1010 *
  • Value3.

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

  • Id (это будет мой собственный автоматически сгенерированный Id);
  • KeyId;
  • Значение1.

Я вижу 2 способа сделать это:

  1. Создать триггер, который при добавлении записей в Log1 автоматически создаст запись в Log2 с необходимыми данными;
  2. Реализация SP, которая примет все необходимые данные для таблицы Log1 и создаст записи в обеих таблицах, а затем попросит авторов этих приложений использовать SP вместо прямого запроса INSERT.

Как вы думаете, что является лучшим способом в этом случае и почему?

Большое спасибо за вашу помощь.

P.S. Я использую MS SQL 2005

Ответы [ 4 ]

2 голосов
/ 15 февраля 2011

Перейти с вариантом 1.

Это означает, что таблицы будут синхронизированы должным образом, даже если «правильный» интерфейс хранимой процедуры не используется, и будет проще и эффективнее вставить несколько строк (Как бы вы сделали это с помощью хранимой процедуры в SQL Server 2005? - Вызывать это несколько раз? Сначала преобразовать все данные в формат XML?)

1 голос
/ 15 февраля 2011

Если вы используете триггер, помните, что, как кажется, и Log1, и Log2 используют столбцы идентификаторов, что вы не можете использовать SELECT @@IDENTITY для возврата PK Log1 - вам нужно будет использовать SCOPE_IDENTITY().

С другой стороны, если вы используете SPROC, вы можете отозвать привилегии INSERT для вашей таблицы (почти) у каждого и вместо этого предоставить EXEC на SPROC. Таким образом, доступ к вашему столу должен быть достаточно хорошо защищен.

1 голос
/ 15 февраля 2011

Единственный способ действительно гарантировать целостность ваших данных - с помощью триггера. Всегда есть вероятность, что кто-то выполнит операцию (массовую операцию, оператор вставки SQL и т. Д.), Которая обойдет ваш SP.

0 голосов
/ 15 февраля 2011

Выберите вариант 2.

По возможности следует избегать триггеров.

Одна не столь очевидная причина: вы когда-нибудь использовали средства репликации SQL Server?Триггеры не будут очень простыми для воспроизведения.(то есть это не так просто, как пара кликов, как, например, для таблиц).Но я ухожу от темы ... Нижняя строка, триггеры зло ... избегайте, когда можете.причины: триггеры не так просто увидеть как другие объекты в СУБД.На стороне приложения они невидимы, и если их недостаточно документировать, они, как правило, забываются.Если в схему внесены изменения ... о, хорошо, проще поддерживать вещи с помощью хранимых процедур.

...