Partager via

Давайте поправим DRI на parent-child

  • Article

Уважаемые коллеги.

Активный участник нашего SQL Serverного сообщества Александр Григорьевич Бондарь зафайлил на коннекте пожелание исправить поведение декларативной ссылочной целостности в случае, когда таблица связана сама на себя.

Скрипт воспроизведения приводится на https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=470632&wa=wsignin1.0, он не бог весть, какой хитрый, тем не менее я прокомментирую, что называется, на пальцах.

Когда две таблицы связаны отношением первичный-внешний ключ и мы хотим, например, грохнуть какой-нибудь РК из родительской таблицы, возможны, как известно, три поведения: NO ACTION - не пущать, если в дочерней таблице есть записи, ссылающиеся на эту родительскую, CASCADE - удалить ссылающиеся дочерние записи из таблицы внешнего ключа (и далее по каскаду, если у нее, в свою очередь, есть дочерние таблицы), SET NULL/SET DEFAULT - поставить в дочерних записях поле внешнего ключа в NULL или значение по умолчанию, елико сие возможно. Аналогично для обновления.

Все хорошо за исключением случая, когда РК-FK отношение определено на одной таблице. Типичный пример - реализация иерархии, как, допустим, делается в измерении parent-child. Здесь она предлагает ставить только NO ACTION, т.к. боится зацикливания. Какое зацикливание? Что плохого, если, допустим, при удалении родительской записи ставить NULL у нее непосредственных детей, что будет означать, что они осиротели? Я считаю, нам надо поддержать Александра Григорьевича и проголосовать за то, чтобы эту фичу поправили. Никого не собираюсь с пеной у рта агитировать, но если вы считаете так же, просто обращаю внимание, что риквест имеет место быть и можно зайти по вышеприведенной ссылке и кликнуть на правую звездочку, чтобы поднять его рейтинг. Также можно кликнуть рядом на Validation: View or Add и отметить Yes, I am able to validate that this issue occurs, потому что действительно такое поведение наблюдается в том числе в 2008-м; скрипт там имеется, можете проверить.

Сделаем SQL Server лучше.