MS SQL Trigger обновить вызов мертвой блокировки?

Question

У меня есть две таблицы. Клуб и Тренер. Между ними 0,1 - 0,1 отношения (у тренера может быть ноль или один клуб. У клуба может быть ноль или один тренер). Когда я хочу сменить тренера данного клуба, я должен обновить клубную таблицу. Так что я должен сменить idCoach этого клуба. Предположим, что новый тренер (вновь назначенный тренер данного клуба) уже является тренером какого-то другого клуба. Я должен установить в Null field idCoach этого клуба, потому что его тренер будет назначен в другой клуб. Кроме того, если клуб, для которого я хочу сменить тренера, уже имеет тренера, тогда я должен установить для idClub этого тренера (в таблице тренеров) значение Null.

Все вышеизложенное также относится и к тому, когда я хочу сменить клуб определенного тренера. (Необходимо установить значение Null idCoach в предыдущем клубе данного тренера и установить значение null idCoach нового клуба).

Те же проблемы могут возникать, когда я вставляю новую запись в таблицу Club или Coach или удаляю существующую (при вставке, обновлении и удалении мне нужно следить за соответствующими ссылками и отсоединять их).

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

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

Как это решить?

Это первый раз, когда я работаю с триггерами, так что извините заранее, за это большое объяснение простой вещи.

Ура!

Answer 1

Можно ли иметь третью таблицу, которая может содержать отношения? Я думаю, что это будет простой подход к работе.

Просто удалите запись из новой таблицы, если тренер выйдет из клуба. Вставьте запись для тренера, вступающего в новый клуб.

Надеюсь, это поможет.

Answer 2

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

Answer 3

Я согласен с шахкалпешем - ваш дизайн должен включать в себя таблицу Coach, таблицу Club, третью таблицу (ClubCoach?) Для хранения отношений. Тогда все, что вам нужно будет сделать, это применить правило, согласно которому тренер не может быть назначен более чем в один клуб (и наоборот) извне.

В качестве альтернативы, вы можете просто иметь таблицы тренеров и клубов с idClub в таблице тренеров (с соблюдением правила один клуб на каждого тренера) и применять правило одного тренера на клуб извне.

Answer 4

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

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

С учетом сказанного вы можете использовать синтаксис If Update (FieldName), чтобы обновлять только те таблицы, которые вам действительно нужны. Если вам нужно остановить рекурсивный триггер, вы можете предотвратить это, проверив TRIGGER_NESTLEVEL ()