iljyКакой вы скучный, все вам на пальцах надо разжевывать...
sphinx_mvПроблема НЕ возникает из-за разрешения изменений ПК - проблемы МОГУТ возникнуть. А могут и НЕ возникнуть...
И если проблема ВОЗНИКЛА - есть ВЕСЬМА существенная вероятность, что надо "что-то менять в консерватории", ака, в логике и структуре БД.
Да, и изменение должно заключаться в создании суррогатного неизменяемого ключа.

Ваша проблема в том, что Вы требуете этого независимо от задачи...
При этом, вроде бы, соглашаясь, что ЕСТЬ много задач, которые ПРЕКРАСНО могут жить даже с изменяемым естественным ключом.
iljysphinx_mvВаш пример?
...
Вот и запустите его... О результатах не забудьте доложить...
Надеюсь, Вы НЕ получите message 547, level 16, state 1... Но это вряд ли...

Зашибись! А ничего, что я писал про INSTEAD OF триггер? И ах простите - я не ткнул вас носом, что приведенный код работает в ситуации, когда отсутствуют декларативные связи и поддержание целостности целиком возложено на триггеры. Хорошо, ткну сейчас. Естественно при наличии декларативной связи код триггера усложняется:

ИCХОДНЫЙ ВАШ код НЕ РАБОТАЕТ - потому ЭТОТ пример идет лесом и очень далеко... Это во-первых...
Во-вторых... Перечитайте ВСЕ ваши посты и НАЙДИТЕ в каком из них ПОЯВЛЯЕТСЯ INSTEAD OF - кстати, уже после того, как Вам указали на НЕ работоспособность Вашего кода...
В-третьих... Ваш ИСХОДНЫЙ пример НЕ сработает даже внутри INSTEAD OF триггера...
В-четвертых. Обсуждалась ДЕКЛАРАТИВНАЯ ссылочной целостности и Ваши неоглашенные допущения об ее отсутствии в качестве аргумента восприниматься НЕ МОГУТ даже сейчас, когда Вы их снизошли изложить...
iljysphinx_mvЕсли при удалении из таблицы A Вашего примера таблица D попадает под обработку, сколько по Вашему раз должны были бы сработать (сугубо теоретически) триггера (при их наличии) этой таблицы? Каскадные удаления по таблицам B и C не зависят друг от друга... Соответственно, и триггеры таблицы D имеют все шансы отработать (независимо) тоже два раза... По одним и тем же данным... Чего в этом случае будет стоить результат подобной обработки - на Ваше собственное усмотрение.
Это была попытка разумного объяснения (на пальцах)...

Вообще-то наличие триггеров - это уже дополнительное условие, при котором каскад может давать проблемы. Да и условие-то хиленькое. С какого перепугу триггера сработают на одних и тех же данных? Первый каскад что-то удалит из таблицы - сработает триггер, после чего второй будет что-то удалять из того, что останется, и триггер сработает на новых данных. Да и потом, объединить таблицы deleted и запустить триггеры AFTER один раз - не великая проблема. А INSTEAD OF триггеры при наличии каскадной связи в принципе запрещены. Так что хиленький примерчик.

Наличие триггеров - никакое не "дополнительное" условие! Это стандартная, хорошо документированная функциональность сервера. Когда использование стандартной функциональности начинают влиять на невозможность использования каких-то Ваших заморочек - может проблема в Ваших заморочках?

Кстати, если вам еще не надоело гнуть пальцы, рассмотрите ситуацию, когда ДВА разных удаления (из таблицы B и из таблицы C) в каскадной операции удаления/обновления из таблицы A пытаются обратиться к одной и той же записи в таблице D - такое может быть? Что со взаимными блокировками делать будете? Какую часть ВСЕЙ операции (все модификации во ВСЕХ таблицах) отменять "по таймауту"? Намекну: отмена любой из них откатит ВСЮ операцию - одна транзакция, однако...

И что Вы уперлись в INSTEAD OF? Разве Вы не в курсе, что есть еще и другие типы триггеров, которых в отличие от INSTEAD OF может даже быть больше одного на каждый вид операции?
iljysphinx_mvпропущено...
К чему мне искать для Вас обобщенные случаи, если Вы даже в своих частных не особо разобрались?
Разобрался я в ваших частных. Хреновенькие они.

Тут, скорее, Вы хреновенько разобрались... Но, "в общем случае" это излечимо...
iljysphinx_mvпропущено...
Не более Вашего - " естественный ключ у вас тут напрашивается (car, part)" (с)...
Ну а кой же он тут? Вполне себе составной естественный ключ.
Вы вообще с декларацией этих полей в таблице успели ознакомиться?
Чего-то я как-то не припомню (из реальной жизни) ни автомобиля "1", ни гайки "10"...

iljysphinx_mvВаша проблема в том, что Вы требуете этого независимо от задачи...
Вы издеваетесь чтоли? Я всю дорогу говорю о том, что создавать суррогатный ключ нужно только в случае реальной необходимости. И один из признаков, что необходимость такая есть, это возможные изменения натурального ПК. Но я сразу говорил что неизменяемость - "очень и очень существенное пожелание к ПК", и нигде не говорил, что это железное требование. А дальше меня начали спрашивать, какие проблемы может повлечь изменение ПК, и я начал приводить примеры возможных проблем. Я нигде не говорил, что они обязательно возникнут.

У Вас мысли отличаются от того, что вы пишите: не Вы ли писали, что ПК не должен меняться? Кто и какого это запретил?!
И не Вы ли писали, что "проблемы возникают" (даже без всяких "иногда", кстати)? А они всего лишь МОГУТ ИНОГДА возникнуть...
Даже некоторое увеличение нагрузки при обновлении связанных таблиц, увеличение занимаемого базой дискового пространства и усложнение синтаксиса запросов очень не всегда становятся проблемой...
iljysphinx_mv ИCХОДНЫЙ ВАШ код НЕ РАБОТАЕТ - потому ЭТОТ пример идет лесом и очень далеко... Это во-первых...
Во-вторых... Перечитайте ВСЕ ваши посты и НАЙДИТЕ в каком из них ПОЯВЛЯЕТСЯ INSTEAD OF - кстати, уже после того, как Вам указали на НЕ работоспособность Вашего кода...
В-третьих... Ваш ИСХОДНЫЙ пример НЕ сработает даже внутри INSTEAD OF триггера...
В-четвертых. Обсуждалась ДЕКЛАРАТИВНАЯ ссылочной целостности и Ваши неоглашенные допущения об ее отсутствии в качестве аргумента восприниматься НЕ МОГУТ даже сейчас, когда Вы их снизошли изложить...

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

После того, как Вы с пеной у рта утверждали, что неработающий в обсуждаемых условиях код обязательно будет работать - мне от этого сугубо... Одним "гениальным" (censored) больше... одним меньше... Я их уже столько повидал...
iljysphinx_mvНаличие триггеров - никакое не "дополнительное" условие! Это стандартная, хорошо документированная функциональность сервера. Когда использование стандартной функциональности начинают влиять на невозможность использования каких-то Ваших заморочек - может проблема в Ваших заморочках?

Нет уж, это именно дополнительное условие - множественные каскадные удаления должны быть запрещены при наличии триггеров. Соответственно мы должны запрещать создание множественных каскадов при наличии триггеров и создание триггеров при наличии множественых каскадов (как собственно делается для INSTEAD OF-триггеров и любых каскадов). Да и то кстати не факт.

Вы уж определитесь - Вам шашечки или ехать?
Еще чуть-чуть, и Вы начнете требовать отмены использования хранимых процедур и заставлять выполнять всю обработку данных на клиенте...
iljysphinx_mvКстати, если вам еще не надоело гнуть пальцы, рассмотрите ситуацию, когда ДВА разных удаления (из таблицы B и из таблицы C) в каскадной операции удаления/обновления из таблицы A пытаются обратиться к одной и той же записи в таблице D - такое может быть? Что со взаимными блокировками делать будете? Какую часть ВСЕЙ операции (все модификации во ВСЕХ таблицах) отменять "по таймауту"? Намекну: отмена любой из них откатит ВСЮ операцию - одна транзакция, однако...

Какие взаимные блокировки в рамках одной сессии? Кто с кем за что будет бороться?
А не расскажете как каскадные удаления/обновления из B и С будут выполнять модификации в D?
Напоминаю, если у вас с памятью что-то случилось, модификации в B и C вызваны каскадными операциями в A...
Т.е. выполняются в рамках одного процесса. Вероятность параллельного выполнения больше 0. Между потоками начинается соревнование за ресурсы, "проигравший" поток ждет снятия блокировок с захваченной другим потоком таблицы. Дождется?
iljy Или вы про распараллеливание решили поговорить? Так оно при каскадных операциях обычно запрещено ( Restrictions on Parallel DML ).

Очччееень умнО! Это просто пять!
Какое, простите, отношение Oracle имеет к MSSQL?
Может тогда Вы нам расскажете про мутации таблиц на Oracle?.. И про "тривиальность" их обхода?..
iljysphinx_mvИ что Вы уперлись в INSTEAD OF? Разве Вы не в курсе, что есть еще и другие типы триггеров, которых в отличие от INSTEAD OF может даже быть больше одного на каждый вид операции?
А вы разве не в курсе, что реализовать каскадное удаление/изменение при наличии декларативного ограничения вида FOREIGN KEY ... ON DELETE/UPDATE NO ACTION можно только INSTEAD OF/BEFORE триггером? Ну значит теперь будете.

Я Вам разве УЖЕ не говорил, что если возможности декларативной ссылочной целостности меня НЕ будут устраивать, я ее реализую на триггерах БЕЗ ее использования? Хотя, как я мог забыть - это же "бредятина" (с)...
iljyА при каскадах INSTEAD OF триггеры запрещены (я об этом сказал), так что мы однозначно говорим о проблемах при наличии AFTER-триггеров (простите, что забыл сказать об этом явно большими буквами ).

Если Вы не знаете как запустить триггер INSTEAD OF в рамкак каскадной операции, это совершенно не значит, что такие триггеры ЗАПРЕЩЕНЫ. Но это так... К слову, пришлось...
iljysphinx_mvВы вообще с декларацией этих полей в таблице успели ознакомиться?
Чего-то я как-то не припомню (из реальной жизни) ни автомобиля "1", ни гайки "10"...
Видите ли в чем дело... Вспомните, Ваше Высочество, ведь
Суррога́тный ключ — это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого — служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД, а генерируется искусственно.. Так что Вы безусловно абсолютно точно и полно подметили, что ключи car и part являются несомненно суррогатными для таблиц Автомобили и Запчасти. Но позволю себе нижайше обратить Ваше просвященное внимание на то, что для таблицы test эти поля являются информационными, поскольку наверняка (это допущение, основанное на предположениях о предметной области ТС, но я смею надеяться, что Ваш беспристрастный взгляд сочтет сие допущение имеющим право на существование) ссылаются на соответствующие поля таблиц Автомобиль и Запчасти соответственно. Следствием же этого является тривиальный факт, что ключ, образованный этими полями, никак не может быть суррогатным.
Составной ключ на основе суррогатных полей быть "естественным" никак не может... По очень простой причине - ну, не несет он непосредственной полезной информационной нагрузки ни из какой предметной области... Это так, к сведению...

iljysphinx_mvпропущено...
После того, как Вы с пеной у рта утверждали, что неработающий в обсуждаемых условиях код обязательно будет работать - мне от этого сугубо... Одним "гениальным" (censored) больше... одним меньше... Я их уже столько повидал...
Когда нечего сказать по существу - цепляются к формальностям...

Неслабая такая формальность - предъявление претензий к НЕРАБОТАЮЩЕМУ фрагменту кода...
iljysphinx_mvОчччееень умнО! Это просто пять!
Какое, простите, отношение Oracle имеет к MSSQL?
Позвольте обратить Ваше просвещенное внимание на постенький факт: MSSQL до сих пор не умеет распараллеливать DML-операции. А когда научится (хотя по-моему даже в Denali этого не обещают) - решение проблемы каскадов можно слизнуть из оракла.

То есть, мусье как бы помягче выразиться, "несколько не в курсе", что MSSQL "не умеет" распараллеливать DML еще как бы не с 7 версии?
И мусье не в курсе, что MSSQL и Oracle весьма отличаются архитектурой, и, чтобы чего-то "слизнуть" с одного на другой, нужно весьма неслабо корежить продукт - с неизвестным результатом и практически полной обратной несовместимостью?
Уж после чего-чего, но после ТАКОГО к Вам вопросов я больше НЕ ИМЕЮ...
iljysphinx_mvСоставной ключ на основе суррогатных полей быть "естественным" никак не может... По очень простой причине - ну, не несет он непосредственной полезной информационной нагрузки ни из какой предметной области... Это так, к сведению...
Для тех кто в танке - повторяем нашу передачу:
Суррога́тный ключ — это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого — служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД , а генерируется искусственно.
На всякий случай персонально для Вас уточню - первичные ключи других таблиц являются какими-либо другими данными из БД.
И где же Вам такую траву продают-то?