Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
andrej2005 Member Откуда: Сообщений: 142 |
Мне необходимо написать триггер для каскадного обновления, раньше этого не делал, поэтому интересуюсь. Не охота открывать новую тему. У меня три таблицы связаны форейнами, также определены бизнес правила, которые не пускают каскадное обновление, определенное в ключах. |
8 апр 14, 11:34 [15848080] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А вы где-то в предложенном скрипте увидели FK constraint-ы ? |
8 апр 14, 11:35 [15848097] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
И еще один вопрос, если в триггере удалять форейны, с какими рисками это связано? Что будет если триггер удалит форейн, а какой-нибудь пользователь в этот момент изменит связанное поле и внесет туда чушь какую-нибудь? Хотя, по идее, идея трансакций такое исключает, но мне нужно подтверждение специалистов! Спасибо за ответы! :) |
8 апр 14, 11:41 [15848134] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
Glory, я их там не вижу, это правда, но по идее они там должны быть, правда? |
8 апр 14, 11:42 [15848143] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
По чьей идеи ? |
||
8 апр 14, 11:47 [15848182] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
если я правильно понял, вы их там просто не устанавливали, экономив время при написании скрипта, хотя их там нужно ставить по самой идее |
||
8 апр 14, 11:50 [15848209] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
по идее реляционной ДБ |
||||
8 апр 14, 11:51 [15848220] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ну если ваша идея реляционной базы _требует_ наличие FK constraint-ов для всех таблиц, то поставьте их В чем проблема ? |
||
8 апр 14, 11:54 [15848239] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47047 |
Если они так мешают, что кушать не можете? А если поставили, то будьте любезны их не нарушать - Вы же много думали, прежде чем так сделать? Обычно простые пользователи не должны иметь права менять структуру БД. Так как же можно даже думать о том, чтобы удалять FK в триггере? |
||||
8 апр 14, 11:55 [15848242] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
iap, постоянно бороться с FK в моей ДБ не надо, но может возникнуть необходимость изменить значение первичного ключа, поэтому и хочу написать триггер на обновление в зависимых таблицах, поскольку стандартный механизм обновления в определении ключа не работает из-за бизнес правила. |
8 апр 14, 12:08 [15848359] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47047 |
никогда не менять значение PK. Для этого делать PK не естественным, а суррогатным. P.S. Меня за такой совет сейчас наверное съедят. Но я сам всегда так делаю. |
||
8 апр 14, 12:16 [15848451] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Стандартный механизм - это каскадные обновления внешних ключей что ли ? |
||
8 апр 14, 12:17 [15848464] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
ну, я считаю INSERT And UPDATE Specification в FK стандартным средством, может я ошибаюсь... |
||||
8 апр 14, 12:23 [15848525] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
И как же бизнесс правила запрещают срабытыванию каскадных операций ? |
||
8 апр 14, 12:26 [15848548] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
Не согласен с тем, что значение первичного ключа нечто святое и некасательное, в моем случае, может возникнуть ошибка при его определении, а ошибку эту не найдешь сразу, только по прошествии нескольких месяцев. Из-за этого и весь сыр-бор! Или вы предлагаете определять новый правильный ключ, лезть в таблицы и менять на правильное значение? |
||||
8 апр 14, 12:30 [15848594] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вы путаете естественные и суррогатные ПК. И начинаете холивар ЗВ Суррогатный ПК не меняется. |
||
8 апр 14, 12:33 [15848614] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
почему-то выполняется условие бизнес правила по которому вылетает в ROLLBACK TRANSACTION |
||||
8 апр 14, 12:37 [15848646] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ну если ваша новое знаение ПК нарушает бизнесс правила, то это будет происходить вне зависимомти от наличия каскадных операций |
||
8 апр 14, 12:43 [15848708] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
да, у меня естественный ключ, сурогатный не устраивает |
||||
8 апр 14, 12:50 [15848770] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Тогда в нормальных системах естественный ключ делают АльтернативнымКлюч-ом. А ПК оставлют суррогратным и НЕ меняют. |
||
8 апр 14, 12:52 [15848789] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
ого вы завернули! альтернативный ключ? это че за зверь такой? |
||||
8 апр 14, 13:05 [15848919] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
ща глянем, почитаем... |
||
8 апр 14, 13:12 [15848980] Ответить | Цитировать Сообщить модератору |
andrej2005 Member Откуда: Сообщений: 142 |
Думаю, моей проблемы это не решит, если изменю естественный ключ на альтернативный. И все же, вернемся к моему вопросу - по вашему убирать ФК в триггере , а в конце снова ставить, для реализации каскадного обновления связанных таблиц - глупость? Я не пойму почему срабатывает бизнес-правило при стандартном каскадном обновлении. Хотя, по сути, не должно! А как происходит в деталях стандартное каскадное обновлением может мне кто-нибудь объяснить? |
8 апр 14, 14:07 [15849469] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ага. Как в анекдоте Вахтер у всех строгим голосм спрашивал пропуск. А у кого не было, то пускал без него
Потому что вы его так написали ?
Вас интересуют детали на самом низком уровне ? |
||||||
8 апр 14, 14:10 [15849495] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47047 |
andrej2005, Вот так сделать что мешает? ALTER TABLE <ИмяТаблицы> DROP CONSTRAINT <ИмяПервичного ключа>; ALTER TABLE <ИмяТаблицы> ADD CONSTRAINT AlternativeKey UNIQUE(<список полей ключа>); ALTER TABLE <ИмяТаблицы> ADD ID INT NOT NULL IDENTITY; ALTER TABLE <ИмяТаблицы> ADD CONSTRAINT <ИмяПервичного ключа> PRIMARY KEY(ID);А Foreign Keys переписать, разумеется, чтобы на ID ссылались. Поле со свойством IDENTITY апдейтить вообще не получится. А поля, входящие в UNIQUE, - сколько душе угодно. Лишь бы уникальность не нарушалась. |
8 апр 14, 14:21 [15849560] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |