ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужен ли primary key в таблице, организующей связь один ко многим?
25 сообщений из 58, страница 2 из 3
  2  все
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424692
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
GoffmaniljyНесомненно, вот только они доступны только в триггерах FOR EACH ROW, а они есть далеко не во всех СУБД.
а вы имели в виду триггеры STATEMENT, так в них принципиально нельзя достучаться до конкретной записи, по крайней мере в Oracle.

Не очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств. Но для правильного сопоставления двух множеств inserted и deleted необходим неизменяющийся уникальный ключ, одноpначно идентифицирующий запись. Странно, что мне приходится объяснять настолько тривиальные вещи.
Goffmaniljy... Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее...
Необходимость каскадных изменений и удалений, как я понимаю, может возникать только если на этот ключ есть ссылка из других таблиц, или еще есть варианты?
? И что? В этом случае запрещено вешать на таблицу триггеры? Вы чего хотите сказать-то? Сформулируйте мысль.
Goffmaniljyэээээ.... Какая связь между ведением журнала изменений, с указанием кто и когда изменил запись, и ссылочной целостностью??
Потому что таблица журнала в этом варианте ссылается на таблицу с данными, надежнее всего это сделать с помощью внешнего ключа, или не так?
Безусловно не так. При такой организации журнала принципиально теряется возможность отследить историю изменений записи, уже удаленной из основной таблицы.
...
Рейтинг: 0 / 0
04.09.2011, 20:58
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424706
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mviljyпропущено...

Несомненно, вот только они доступны только в триггерах FOR EACH ROW, а они есть далеко не во всех СУБД.

FOR EACH ROW (с новыми и старыми значениями) весьма несложным образом "эмулируется" даже на весьма "древних" версиях MSSQL.
Надо быть неслабо больным на голову, чтобы эмулировать в MSSQL триггеры FOR EACH ROW, но дело даже не в этом. При проходе курсорами по таблицам inserted и deleted нет никаких гарантий, что идти по записям они будут синхронно, потому что 1 - изменение значения ПК может изменить порядок записей, и 2 - их может быть в принципе разное количество (см. MERGE).
sphinx_mviljyпропущено...

Да ну? Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее, и СУБД тупо не дает задать для них ON DELETE CASCADE, и приходится реализовывать эту функциональность триггерами? По поводу "какую проблему" смотрите выше.
При каскадных удалениях и обновлениях не должно возникать циклических зависимостей в операциях.
Соответственно, никакой разницы между естественными и суррогатными ключами в данном случае нет.
Не должно, но тот же MSSQL очень часто перестраховывается и не дает задавать несколько каскадных ВК на одной таблице.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
use tempdb
create table A (idA int primary key)
create table B (idB int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table C (idC int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table D (idD int primary key,
		idB int foreign key references B(idB) on delete cascade,
		idC int foreign key references C(idC) /*on delete cascade*/)
go
drop table D
drop table C
drop table B
drop table A
Раскоментарьте и выполните.
...
Рейтинг: 0 / 0
04.09.2011, 21:14
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424859
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств.
В общем то триггеры для того и существуют, чтобы обрабатывать конкретные записи,
можно конечно в триггерах и множества перелопачивать, но зачем.

iljy? И что? В этом случае запрещено вешать на таблицу триггеры? Вы чего хотите сказать-то? Сформулируйте мысль.
Хотел сказать, что давным давно уже договорились, что ссылочную целостность лучше обеспечивать с помощью суррогатных ключей и с этим никто не спорит.

iljyБезусловно не так. При такой организации журнала принципиально теряется возможность отследить историю изменений записи, уже удаленной из основной таблицы.
Соглашусь, только в этом случае в журнале придется хранить не только ID, но и все поля удаленной записи
...
Рейтинг: 0 / 0
05.09.2011, 06:58
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424877
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств. Но для правильного сопоставления двух множеств inserted и deleted необходим неизменяющийся уникальный ключ, одноpначно идентифицирующий запись. Вы уж определитесь - нужны вам конкретные записи или нет. Ваше "правильное сопоставление" нужно только в том случае, если вы хотите с конкретными записями работать. А при "обработке множеств" важно лишь какое множество связей было до изменения и какое стало после - составного ключа для такого определения вполне достаточно.
...
Рейтинг: 0 / 0
05.09.2011, 08:52
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424879
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
GoffmaniljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств.
В общем то триггеры для того и существуют, чтобы обрабатывать конкретные записи,
можно конечно в триггерах и множества перелопачивать, но зачем.
Если бы это было так, то первичны были бы триггеры FOR EACH ROW, а триггеры STATEMENT в таком случае делать скорее всего вообще бы не стали. Тем не менее STATEMENT есть во всех СУБД, а FOR EACH ROW только в очень некоторых.
Скуль это в принципе язык обработки множеств, вся построчная обработка в нем - поздние привнесения, причем, в случае, например, линейки Sybase, сделаные "шоб було".
Goffmaniljy? И что? В этом случае запрещено вешать на таблицу триггеры? Вы чего хотите сказать-то? Сформулируйте мысль.
Хотел сказать, что давным давно уже договорились, что ссылочную целостность лучше обеспечивать с помощью суррогатных ключей и с этим никто не спорит.
Ссылочную целостность удобнее обеспечивать с помощью неизменяющихся ключей, будут они при этом натуральные или суррогатные - не столь важно.
GoffmaniljyБезусловно не так. При такой организации журнала принципиально теряется возможность отследить историю изменений записи, уже удаленной из основной таблицы.
Соглашусь, только в этом случае в журнале придется хранить не только ID, но и все поля удаленной записи
Интересно, а как вы планируете отслеживать историю изменений, не сохраняя удаленный значения?
...
Рейтинг: 0 / 0
05.09.2011, 08:58
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424986
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljysphinx_mvпропущено...

FOR EACH ROW (с новыми и старыми значениями) весьма несложным образом "эмулируется" даже на весьма "древних" версиях MSSQL.
Надо быть неслабо больным на голову, чтобы эмулировать в MSSQL триггеры FOR EACH ROW, но дело даже не в этом. При проходе курсорами по таблицам inserted и deleted нет никаких гарантий, что идти по записям они будут синхронно, потому что 1 - изменение значения ПК может изменить порядок записей, и 2 - их может быть в принципе разное количество (см. MERGE).


Надо быть весьма "неслабо больным на голову", чтобы вообще предполагать хоть какой-то гарантированный порядок обработки записей в любых запросах. Это во-первых...

Во-вторых... FULL OUTER JOIN из inserted и deleted, связанных по PK, с правильной сортировкой решают подавляющую часть проблем и с порядком записей, и с разницей в количестве... И даже при изменениях значения первичного ключа...

iljysphinx_mvпропущено...

При каскадных удалениях и обновлениях не должно возникать циклических зависимостей в операциях.
Соответственно, никакой разницы между естественными и суррогатными ключами в данном случае нет.
Не должно, но тот же MSSQL очень часто перестраховывается и не дает задавать несколько каскадных ВК на одной таблице.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
use tempdb
create table A (idA int primary key)
create table B (idB int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table C (idC int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table D (idD int primary key,
		idB int foreign key references B(idB) on delete cascade,
		idC int foreign key references C(idC) /*on delete cascade*/)
go
drop table D
drop table C
drop table B
drop table A
Раскоментарьте и выполните.[/quot]

Вы сначала прочитайте , ЧТО Вам сервер написал!.. Я буду не я, если там не было про наличие циклической ссылки, что является ограничением для каскадных операций для внешних ключей.
Нарисуйте на листике бумаги свои 4-ре таблицы. Укажите все связи линиями. И Вы увидите это "кольцо"... Если захотите...
И, обращаю Ваше внимание - никакой разницы для суррогатных и естественных ключей в данном примере НЕ будет. Как впрочем и при использовании составных ключей...
...
Рейтинг: 0 / 0
05.09.2011, 10:59
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425074
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mviljyпропущено...

Надо быть неслабо больным на голову, чтобы эмулировать в MSSQL триггеры FOR EACH ROW, но дело даже не в этом. При проходе курсорами по таблицам inserted и deleted нет никаких гарантий, что идти по записям они будут синхронно, потому что 1 - изменение значения ПК может изменить порядок записей, и 2 - их может быть в принципе разное количество (см. MERGE).


Надо быть весьма "неслабо больным на голову", чтобы вообще предполагать хоть какой-то гарантированный порядок обработки записей в любых запросах. Это во-первых...

Во-вторых... FULL OUTER JOIN из inserted и deleted, связанных по PK, с правильной сортировкой решают подавляющую часть проблем и с порядком записей, и с разницей в количестве... И даже при изменениях значения первичного ключа...

1. В каком месте я предполагал порядок обработки? При неизменяющихся ключах можно хотя бы задать одинаковую сортировку явно.
2. При использовании FULL JOIN с правильными неизменяющимися ПК никакой порядок уже не важен. А при изменении ПК никакой FULL JOIN вам записи правильно не сопоставит.

sphinx_mviljyпропущено...

Не должно, но тот же MSSQL очень часто перестраховывается и не дает задавать несколько каскадных ВК на одной таблице.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
use tempdb
create table A (idA int primary key)
create table B (idB int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table C (idC int primary key,
		 idA int foreign key references A(idA) on delete cascade)
create table D (idD int primary key,
		idB int foreign key references B(idB) on delete cascade,
		idC int foreign key references C(idC) /*on delete cascade*/)
go
drop table D
drop table C
drop table B
drop table A
Раскоментарьте и выполните.

Вы сначала прочитайте , ЧТО Вам сервер написал!.. Я буду не я, если там не было про наличие циклической ссылки, что является ограничением для каскадных операций для внешних ключей.
Нарисуйте на листике бумаги свои 4-ре таблицы. Укажите все связи линиями. И Вы увидите это "кольцо"... Если захотите...
И, обращаю Ваше внимание - никакой разницы для суррогатных и естественных ключей в данном примере НЕ будет. Как впрочем и при использовании составных ключей...
Вот и прочитайте. А потом покажите, где в направленном графе ((A->B),(A->C),(B->D),(C->D)) цикл.
Потом замените on delete на on update и попробуйте реализовать каскадное обновление ВК в таблице D при изменении C(idC). И расскажите, чем облегчит ситуацию изменяемый суррогатный ключ.
...
Рейтинг: 0 / 0
05.09.2011, 11:44
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425224
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljysphinx_mvпропущено...


Надо быть весьма "неслабо больным на голову", чтобы вообще предполагать хоть какой-то гарантированный порядок обработки записей в любых запросах. Это во-первых...

Во-вторых... FULL OUTER JOIN из inserted и deleted, связанных по PK, с правильной сортировкой решают подавляющую часть проблем и с порядком записей, и с разницей в количестве... И даже при изменениях значения первичного ключа...

1. В каком месте я предполагал порядок обработки? При неизменяющихся ключах можно хотя бы задать одинаковую сортировку явно.
2. При использовании FULL JOIN с правильными неизменяющимися ПК никакой порядок уже не важен. А при изменении ПК никакой FULL JOIN вам записи правильно не сопоставит.


1) IMHO, невозможность сопоставить ключи формально (неявным образом) указывает на невозможность определенным образом отсортировать записи из этих двух псевдо-таблиц.

2) По сути, модификация значения первичного ключа ни много, ни мало, но означает всего лишь удаление записи со старым значением и добавление записи с новым значением. В чем проблема? Разве команды INSERT и DELETE делают не тоже самое?
Нужно перенести логику работы, срабатывающих на них триггеров на триггеры по UPDATE. Разграничить удаленные, добавленные
и измененные записи проблем не составляет даже в принципе...
Проблемы изменения ключей связанных таблиц указывают на не очень правильный дизайн БД - не более того.
И очень, кстати, не факт, что сервер (и не обязательно MSSQL) позволит изменить эти ключи триггером даже в случае поддерживаемой возможности сопоставления нового и старого значения ключа...

iljysphinx_mvпропущено...

Вы сначала прочитайте , ЧТО Вам сервер написал!.. Я буду не я, если там не было про наличие циклической ссылки, что является ограничением для каскадных операций для внешних ключей.
Нарисуйте на листике бумаги свои 4-ре таблицы. Укажите все связи линиями. И Вы увидите это "кольцо"... Если захотите...
И, обращаю Ваше внимание - никакой разницы для суррогатных и естественных ключей в данном примере НЕ будет. Как впрочем и при использовании составных ключей...
Вот и прочитайте. А потом покажите, где в направленном графе ((A->B),(A->C),(B->D),(C->D)) цикл.
Потом замените on delete на on update и попробуйте реализовать каскадное обновление ВК в таблице D при изменении C(idC). И расскажите, чем облегчит ситуацию изменяемый суррогатный ключ.

Во-первых, сколько раз в ВАШЕМ направленном графе встречается ребро, заканчивающееся таблицей D?
Посчитать (специально для Вас выделил жирным) и увидеть, что явно БОЛЬШЕ 1 раза - слабо?
А теперь МОЙ вопрос... От того, что ключ составной, суррогатный, естественный и т.п., количество "циклов" изменится?
Чего-то мне подсказывает, что ни разу... Соответственно, никакой разницы между ними НЕТ!

Во-вторых. Не затруднитесь ли Вы указать, в каком месте и какими путями могут закончиться каскадные действия по UPDATE и DELETE для таблицы A? Наверное, все же в наличие, как минимум, 2 возможных пути, каждый из которых упирается в ту самую таблицу D...

Короче, доки - они рулес:
http://msdn.microsoft.com/ru-ru/library/ms186973.aspx Последовательности каскадных ссылочных действий, запускаемые отдельными инструкциями DELETE или UPDATE, должны образовывать дерево без циклических ссылок. Никакая таблица не должна появляться больше одного раза в списке всех каскадных ссылочных действий, вызванных инструкциями DELETE или UPDATE. Кроме того, в дереве каскадных ссылочных действий к любой из задействованных таблиц должен быть только один путь . Любая ветвь в дереве прерывается, как только встречается таблица, для которой указано действие NO ACTION или вообще не указано действие.
...
Рейтинг: 0 / 0
05.09.2011, 13:17
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425314
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mviljyпропущено...

1. В каком месте я предполагал порядок обработки? При неизменяющихся ключах можно хотя бы задать одинаковую сортировку явно.
2. При использовании FULL JOIN с правильными неизменяющимися ПК никакой порядок уже не важен. А при изменении ПК никакой FULL JOIN вам записи правильно не сопоставит.


1) IMHO, невозможность сопоставить ключи формально (неявным образом) указывает на невозможность определенным образом отсортировать записи из этих двух псевдо-таблиц.

2) По сути, модификация значения первичного ключа ни много, ни мало, но означает всего лишь удаление записи со старым значением и добавление записи с новым значением. В чем проблема? Разве команды INSERT и DELETE делают не тоже самое?
Нужно перенести логику работы, срабатывающих на них триггеров на триггеры по UPDATE. Разграничить удаленные, добавленные
и измененные записи проблем не составляет даже в принципе...

1. Чиво-чиво???
2. По какой такой сути? Опция ON UPDATE CASCADE, например, трактует это совсем не так, для вашей трактовки требуется установка ON UPDATE SET NULL для разрушения связи, причем задать удаление (как при реальном DELETE родительской записи) просто нельзя.
sphinx_mvПроблемы изменения ключей связанных таблиц указывают на не очень правильный дизайн БД - не более того.
И очень, кстати, не факт, что сервер (и не обязательно MSSQL) позволит изменить эти ключи триггером даже в случае поддерживаемой возможности сопоставления нового и старого значения ключа...
Вы вообще топик читали? Или так, мыслию по древу течете? Я с самого начала говорил, что проблемы могут возникать именно при изменении ПК, и не имеет никакого значения, будет он при этом естественным или суррогатным. Просто идея изменять суррогатный ключ приходит только в совсем уж дремучие головы.
И объясните, что именно может помешать серверу изменить конкретные записи при возможности их точно идентифицировать? Давайте рассмотрим простейший случай - триггер допускает модификацию только одной записи (if @@ROWCOUNT > 1 rollback), поэтому проблемы сопоставления нет. Что может мне помешать написать в теле триггера
Код: plaintext
1.
2.
3.
4.
update t1
set ReferenceKeyField = i.KeyField
from MyChildTable t1 join deleted d on t1.ReferenceKeyField = d.KeyField
   left join inserted i on  1 = 1
?
sphinx_mviljyпропущено...

Вот и прочитайте. А потом покажите, где в направленном графе ((A->B),(A->C),(B->D),(C->D)) цикл.
Потом замените on delete на on update и попробуйте реализовать каскадное обновление ВК в таблице D при изменении C(idC). И расскажите, чем облегчит ситуацию изменяемый суррогатный ключ.

Во-первых, сколько раз в ВАШЕМ направленном графе встречается ребро, заканчивающееся таблицей D?
Посчитать (специально для Вас выделил жирным) и увидеть, что явно БОЛЬШЕ 1 раза - слабо?
А теперь МОЙ вопрос... От того, что ключ составной, суррогатный, естественный и т.п., количество "циклов" изменится?
Чего-то мне подсказывает, что ни разу... Соответственно, никакой разницы между ними НЕТ!

Во-вторых. Не затруднитесь ли Вы указать, в каком месте и какими путями могут закончиться каскадные действия по UPDATE и DELETE для таблицы A? Наверное, все же в наличие, как минимум, 2 возможных пути, каждый из которых упирается в ту самую таблицу D...

Вы правда считаете, что я не в состоянии сосчитать до 2х? Вы сами начали говорить про циклические ссылки , теперь уже говорите про множественность путей, определитесь. Естественно их там несколько, только можете обрисовать проблему, которая из-за этого возникает? Конкретную проблему, а не формальное несоответствие докам - как наличие связи D(idB)->B(idB) мешает обновить значение поля idC таблицы D при изменении поля idC таблицы С? Именно это отсутствие реальной логической проблемы я и имел ввиду, говоря, что сервер перестраховывается, запрещая все множественные каскады. И именно для этого приходится создавать триггеры. Но если каскадное удаление никаких трудностей не создает (там просто нет сопоставления), то каскадное изменение (именно изменение связи, а не разрыв и прочее) реализовать триггером невозможно.
Хватит теоретизировать, напишите триггер, обеспечивающий поддержание ссылочной целостности при выполнении
Код: plaintext
update C set idC = idC +  1
...
Рейтинг: 0 / 0
05.09.2011, 14:14
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425318
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyiljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств. Но для правильного сопоставления двух множеств inserted и deleted необходим неизменяющийся уникальный ключ, одноpначно идентифицирующий запись. Вы уж определитесь - нужны вам конкретные записи или нет. Ваше "правильное сопоставление" нужно только в том случае, если вы хотите с конкретными записями работать. А при "обработке множеств" важно лишь какое множество связей было до изменения и какое стало после - составного ключа для такого определения вполне достаточно.
Мне - не нужны. И я ничего не имею против составных ключей. Читайте топик целиком, а не обрывки фраз.
...
Рейтинг: 0 / 0
05.09.2011, 14:17
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425647
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyМне - не нужны. И я ничего не имею против составных ключей. Читайте топик целиком, а не обрывки фраз.
Привожу ниже не обрывки фраз, а полноценные ваши утверждения.

Сначала вы написали, что
iljyА неизменяемый ПК здесь нужен именно для того, чтоб надежно отследить историю изменений конкретной записи, для чего ее нужно однозначно идентифицировать все время ее жизни.

А потом
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств.
Оба утверджения вполне себе логически закончены.

Из второго утверждения следует, что в "скуль" с конкретными записями не работают, а тогда из первого, что неизменяемый ПК здесь не нужен.
Несмотря на это вы, как мне показалось, отстаиваете необходимость неизменяемых ПК. Вот я и хочу понять почему в ваших утверждениях такое противоречие.
...
Рейтинг: 0 / 0
05.09.2011, 16:28
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425665
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljysphinx_mvпропущено...


1) IMHO, невозможность сопоставить ключи формально (неявным образом) указывает на невозможность определенным образом отсортировать записи из этих двух псевдо-таблиц.

2) По сути, модификация значения первичного ключа ни много, ни мало, но означает всего лишь удаление записи со старым значением и добавление записи с новым значением. В чем проблема? Разве команды INSERT и DELETE делают не тоже самое?
Нужно перенести логику работы, срабатывающих на них триггеров на триггеры по UPDATE. Разграничить удаленные, добавленные
и измененные записи проблем не составляет даже в принципе...

1. Чиво-чиво???
2. По какой такой сути? Опция ON UPDATE CASCADE, например, трактует это совсем не так, для вашей трактовки требуется установка ON UPDATE SET NULL для разрушения связи, причем задать удаление (как при реальном DELETE родительской записи) просто нельзя.


1. Таво-таво...
2. Мне В ТРИГГЕРЕ ничего удалять не надо - триггер нужен для обслуживания НЕКОТОРЫХ операций ЛОГИКИ работы БД.
И ситуация с измененным ключем по UPDATE в триггере в-целом логически ничем не отличается от обработки двух других команд INSERT и DELETE.

Добавлю...
3: Если Вы решили обрабатывать ссылочную целостность данных триггерами и на таблицы при этом в довесок навесили еще и декларативную, с использованием внешних ключей, которая Вам дает отлупы - ну, кто ж Вам в этом виноват?!
4: Если уж Вы разрешить в БД изменение первичных ключей (любого типа) - лучше смотрите под ноги, куда наступаете...

iljysphinx_mvПроблемы изменения ключей связанных таблиц указывают на не очень правильный дизайн БД - не более того.
И очень, кстати, не факт, что сервер (и не обязательно MSSQL) позволит изменить эти ключи триггером даже в случае поддерживаемой возможности сопоставления нового и старого значения ключа...
Вы вообще топик читали? Или так, мыслию по древу течете? Я с самого начала говорил, что проблемы могут возникать именно при изменении ПК, и не имеет никакого значения, будет он при этом естественным или суррогатным. Просто идея изменять суррогатный ключ приходит только в совсем уж дремучие головы.
И объясните, что именно может помешать серверу изменить конкретные записи при возможности их точно идентифицировать? Давайте рассмотрим простейший случай - триггер допускает модификацию только одной записи (if @@ROWCOUNT > 1 rollback), поэтому проблемы сопоставления нет. Что может мне помешать написать в теле триггера
Код: plaintext
1.
2.
3.
4.
update t1
set ReferenceKeyField = i.KeyField
from MyChildTable t1 join deleted d on t1.ReferenceKeyField = d.KeyField
   left join inserted i on  1 = 1
?


Собственно, Вам никто ЭТОГО не запрещает НАПИСАТЬ... Сервер САМ скажет, почему ЭТО не будет работать, ЕСЛИ это НЕ будет работать. Потом в документации прочитаете подробнее, если до сих пор не удосужились.
Вы накладываете ограничения на данные, и потом требуете выполнить код, который нарушает эти ограничения...
Это очень сильный ход!..

iljysphinx_mvпропущено...
Во-первых, сколько раз в ВАШЕМ направленном графе встречается ребро, заканчивающееся таблицей D?
Посчитать (специально для Вас выделил жирным) и увидеть, что явно БОЛЬШЕ 1 раза - слабо?
А теперь МОЙ вопрос... От того, что ключ составной, суррогатный, естественный и т.п., количество "циклов" изменится?
Чего-то мне подсказывает, что ни разу... Соответственно, никакой разницы между ними НЕТ!

Во-вторых. Не затруднитесь ли Вы указать, в каком месте и какими путями могут закончиться каскадные действия по UPDATE и DELETE для таблицы A? Наверное, все же в наличие, как минимум, 2 возможных пути, каждый из которых упирается в ту самую таблицу D...

Вы правда считаете, что я не в состоянии сосчитать до 2х? Вы сами начали говорить про циклические ссылки , теперь уже говорите про множественность путей, определитесь. Естественно их там несколько, только можете обрисовать проблему, которая из-за этого возникает? Конкретную проблему, а не формальное несоответствие докам - как наличие связи D(idB)->B(idB) мешает обновить значение поля idC таблицы D при изменении поля idC таблицы С? Именно это отсутствие реальной логической проблемы я и имел ввиду, говоря, что сервер перестраховывается, запрещая все множественные каскады. И именно для этого приходится создавать триггеры. Но если каскадное удаление никаких трудностей не создает (там просто нет сопоставления), то каскадное изменение (именно изменение связи, а не разрыв и прочее) реализовать триггером невозможно.
Хватит теоретизировать, напишите триггер, обеспечивающий поддержание ссылочной целостности при выполнении
Код: plaintext
update C set idC = idC +  1


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

Не хотелось бы расматривать клинические случаи, но когда кто-то начинает приводить примеры, четко подпадающие под ограничения конкретной технологии или платформы и при этом кричит "а оно не работает", это начинает вызывать весьма неоднозначные ассоциации.

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

ЗЫ. А Вы уже разобрались в естественных, суррогатных и составных ключах ?
...
Рейтинг: 0 / 0
05.09.2011, 16:34
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425711
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyiljyМне - не нужны. И я ничего не имею против составных ключей. Читайте топик целиком, а не обрывки фраз.
Привожу ниже не обрывки фраз, а полноценные ваши утверждения.

Сначала вы написали, что
iljyА неизменяемый ПК здесь нужен именно для того, чтоб надежно отследить историю изменений конкретной записи, для чего ее нужно однозначно идентифицировать все время ее жизни.

А потом
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств.
Оба утверджения вполне себе логически закончены.

Из второго утверждения следует, что в "скуль" с конкретными записями не работают, а тогда из первого, что неизменяемый ПК здесь не нужен.
Несмотря на это вы, как мне показалось, отстаиваете необходимость неизменяемых ПК. Вот я и хочу понять почему в ваших утверждениях такое противоречие.
В упор не понимаю, в чем вы усмотрели противоречие. В запросе
Код: plaintext
select * from Table1 t1 join Table2 t2 on t2.id1=t1.id
обрабатываются множества, но сопоставляются конкретные записи. И при анализе журнала изменений вполне себе часто возникает задача отследить историю жизни конкретной записи, для чего приходится обработать множество записей об ее изменениях.
...
Рейтинг: 0 / 0
05.09.2011, 16:50
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425752
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyВ упор не понимаю, в чем вы усмотрели противоречие.
Противоречие в том, что с одной стороны вы утверждаете, что конкретные записи рассматривать не нужно, а в следующей фразе вдруг ратуете за необходимость отслеживания конкретных записей.
Я готов согласится с каждой из альтернатив, но не могу принять сразу обе.
...
Рейтинг: 0 / 0
05.09.2011, 17:04
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425802
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyiljyВ упор не понимаю, в чем вы усмотрели противоречие.
Противоречие в том, что с одной стороны вы утверждаете, что конкретные записи рассматривать не нужно, а в следующей фразе вдруг ратуете за необходимость отслеживания конкретных записей.
Я готов согласится с каждой из альтернатив, но не могу принять сразу обе.
Перечитайте внимательно мой предыдущий пост и осознайте, что операции над множествами определяются в терминах элементов, их составляющих.
...
Рейтинг: 0 / 0
05.09.2011, 17:28
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425867
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mv4: Если уж Вы разрешить в БД изменение первичных ключей (любого типа) - лучше смотрите под ноги, куда наступаете...

У вас все хорошо? Повторяю еще раз - я в самом начале сказал , что проблема возникает именно при разрешении изменять первичные ключи.
sphinx_mviljyпропущено...

Вы вообще топик читали? Или так, мыслию по древу течете? Я с самого начала говорил, что проблемы могут возникать именно при изменении ПК, и не имеет никакого значения, будет он при этом естественным или суррогатным. Просто идея изменять суррогатный ключ приходит только в совсем уж дремучие головы.
И объясните, что именно может помешать серверу изменить конкретные записи при возможности их точно идентифицировать? Давайте рассмотрим простейший случай - триггер допускает модификацию только одной записи (if @@ROWCOUNT > 1 rollback), поэтому проблемы сопоставления нет. Что может мне помешать написать в теле триггера
Код: plaintext
1.
2.
3.
4.
update t1
set ReferenceKeyField = i.KeyField
from MyChildTable t1 join deleted d on t1.ReferenceKeyField = d.KeyField
   left join inserted i on  1 = 1
?


Собственно, Вам никто ЭТОГО не запрещает НАПИСАТЬ... Сервер САМ скажет, почему ЭТО не будет работать, ЕСЛИ это НЕ будет работать. Потом в документации прочитаете подробнее, если до сих пор не удосужились.
Вы накладываете ограничения на данные, и потом требуете выполнить код, который нарушает эти ограничения...
Это очень сильный ход!..

Гениально! Вы не болгарин случайно? У них кивок головой отрицание означает, может вы по аналогии да и нет путаете? Я утверждаю, что приведенный мной код прекрасно сработает (докажете обратное? Без трепотни, а контрпримером?), и ограничения на данные я накладываю самые обычные (привязка к нескольким объектам, являющимся разными ветвями одной иерархии, встречается не так уж редко), и привожу вариант их реализации, который сервер не может реализовать автоматически из-за нарушения формальных завышеных требований (отсутствие множественных путей является одним из достаточных, но не необходимым условием корректности связей с каскадными действиями).
sphinx_mvЕсли я напишу триггер для поддержания ссылочной целостности, Я перестану использовать декларативную ссылочную целостность на внешних ключах...
Госсподи, эту-то бредятину вы откуда выкопали??? Триггер для поддержания целостности частенько приходится использовать даже на неизменяющихся ключах, именно из-за ограничений на множественные каскады. В этом случае декларативная целостность поддерживается ключем ON DELETE NO ACTION, а каскадное удаление реализуется триггером BEFORE/INSTEAD OF.
sphinx_mvНе хотелось бы расматривать клинические случаи, но когда кто-то начинает приводить примеры, четко подпадающие под ограничения конкретной технологии или платформы и при этом кричит "а оно не работает", это начинает вызывать весьма неоднозначные ассоциации.

Именно из-за НАЛИЧИЯ ПОТЕНЦИАЛЬНОЙ проблемы, связанной с удалением из таблицы А сервер и запрещает даже в Вашем примере использование для таблицы D нескольких внешних ключей с каскадным удалением - ЭТО ДЕЙСТВИТЕЛЬНО ТАК СЛОЖНО ПОНЯТЬ?!
Сколько эспрессии А простенько, без эмоций, взять и првести примерчик, когда наличие множественных связей действительно создает логически неразрешимую проблему при каскадном уделении/изменении вы можете? Или будем как заклинание читать мантру "раз это запрещено - значит так надо"?

sphinx_mvА ведь Вы взяли простой (единичный) пример, в котором (формально) можно обойти это ограничение. Вот только сервер - это несколько более "обобщенный движок", который должен правильно и единообразно обрабатывать ПОДОБНЫЕ ситуации ВО ВСЕХ СЛУЧАЯХ. Соотвественно ИМЕННО ДЛЯ ТАКОГО "обощенного случая" установлено ТАКОЕ ограничение.
Еще раз - меньше слов. Просто приведите конкретный пример такого обобщенного случая, и продолжим на его основе. Пока с вашей стороны одни эмоции.
sphinx_mvЗЫ. А Вы уже разобрались в естественных, суррогатных и составных ключах ?
Да вы шутник
...
Рейтинг: 0 / 0
05.09.2011, 17:55
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425888
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyПеречитайте внимательно мой предыдущий пост и осознайте, что операции над множествами определяются в терминах элементов, их составляющих.

А вам советую осознать, что понятия "запись таблицы" и "элемент множества" отнюдь не синонимы.
...
Рейтинг: 0 / 0
05.09.2011, 18:21
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425904
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyiljyПеречитайте внимательно мой предыдущий пост и осознайте, что операции над множествами определяются в терминах элементов, их составляющих.

А вам советую осознать, что понятия "запись таблицы" и "элемент множества" отнюдь не синонимы.
Дааа??? А вот реляционная алгебра оперирует понятием "кортеж", и таблицу определяет как "множество кортежей", а кортеж на практике обычно называют "записью". Вы знаете какие-то другие определения?
...
Рейтинг: 0 / 0
05.09.2011, 18:26
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37425960
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyBogdanov Andreyпропущено...
А вам советую осознать, что понятия "запись таблицы" и "элемент множества" отнюдь не синонимы.
Дааа??? А вот реляционная алгебра оперирует понятием "кортеж", и таблицу определяет как "множество кортежей", а кортеж на практике обычно называют "записью". Вы знаете какие-то другие определения?

Удивлены?
А вот так... Запись таблицы это лишь способ хранения кортежа. Для кортежа не существует понятия "изменение". Кортеж с другими значениями "атрибутов" это уже дургой кортеж и никакой задачи "отслеживания истории конкретного кортежа" в рамках реляционной алгебры нет и быть не может. Конкретный кортеж всегда неизменен и лишь разные отношения (то бишь множества) либо включают его, либо не включают.
Как вы верно заметили алгебра оперирует множествами - то есть отслеживать можно только состояние множеств - временами одни элементы туда входят, другие удаляются, но никакой истории "элементов" нет.

С другой стороны можно реляционную алгебру рассматривать лишь как абстрактную теорию, а на практике оперировать запиясми, как объектами. В этом случае, несомненно можно обсуждать исторю жизни объекта, но тогда ваше утверждение "зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств" становится неверным.
...
Рейтинг: 0 / 0
05.09.2011, 19:16
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37426020
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljy Тем не менее STATEMENT есть во всех СУБД, а FOR EACH ROW только в очень некоторых.

STATEMENT триггеры к сожалению, не дают абсолютно никакой информации об изменяемых данных, по крайней мере в Оракле, поэтому их использование весьма ограничено. Кстати, интересно бы знать какие современные СУБД по-вашему не поддерживают триггеры FOR EACH ROW.

iljyСкуль это в принципе язык обработки множеств, вся построчная обработка в нем - поздние привнесения, причем, в случае, например, линейки Sybase, сделаные "шоб було".

Вы смешиваете понятия, триггеры и построчная обработка - это логика работы СУБД, и к SQL они ни имеют никакого отношения.

iljyСсылочную целостность удобнее обеспечивать с помощью неизменяющихся ключей, будут они при этом натуральные или суррогатные - не столь важно.
Ну да, только натуральный ключ со временем, или при расширении предметной области может перестать быть уникальным, тогда возникнут проблемы, если на него есть ссылки.
Поэтому при наличии иссылк на таблицу лучше сразу использовать суррогатный РК, во избежание.


iljyИнтересно, а как вы планируете отслеживать историю изменений, не сохраняя удаленный значения?
Например не удалять запись, а помечать удаленной. Но в принципе, если вы удалили запись, и сохранили все ее поля в журнале, не очень понятно, какую ценность здесь представляет именно суррогатный ID.
...
Рейтинг: 0 / 0
05.09.2011, 20:14
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37426053
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Goffmaniljy Тем не менее STATEMENT есть во всех СУБД, а FOR EACH ROW только в очень некоторых.

STATEMENT триггеры к сожалению, не дают абсолютно никакой информации об изменяемых данных, по крайней мере в Оракле, поэтому их использование весьма ограничено. Кстати, интересно бы знать какие современные СУБД по-вашему не поддерживают триггеры FOR EACH ROW.
Ах ну да, я совсем забыл, что в оракле триггеры уровня оператора сильно кастрированы. Да, тогда ваши вопросы понятны. FOR EACH ROW-триггеры не поддерживает вся линейка Sybase, в частности MSSQL.
GoffmaniljyСкуль это в принципе язык обработки множеств, вся построчная обработка в нем - поздние привнесения, причем, в случае, например, линейки Sybase, сделаные "шоб було".

Вы смешиваете понятия, триггеры и построчная обработка - это логика работы СУБД, и к SQL они ни имеют никакого отношения.
Не-а. Триггеры уровня оператора точно так же работают в терминах множеств. При этом я естественно понимаю, что потроха СУБД работают на уровне потоков строк.
GoffmaniljyСсылочную целостность удобнее обеспечивать с помощью неизменяющихся ключей, будут они при этом натуральные или суррогатные - не столь важно.
Ну да, только натуральный ключ со временем, или при расширении предметной области может перестать быть уникальным, тогда возникнут проблемы, если на него есть ссылки.
Поэтому при наличии иссылк на таблицу лучше сразу использовать суррогатный РК, во избежание.
Про время не согласен, ключ - он либо уникальный по требованиям бизнес-логики, либо нет. А насчет расширения ПО вопрос весьма филосовский опять же. Как правило уникальное ограничение на натуральный ключ все равно приходится вешать, соответственно изменение логики скорее всего приведет просто к расширению ключа до уникального. Но если такое возможно в обозримой перспективе - тогда действительно проще сразу сделать суррогат.
Вы поймите, что суррогатный ключ - это всегда дополнительные расходы (на хранение ключа, на дополнительные индексы, которые надо модифицировать при вставке-удалении, следить за фрагментацией и т.п.), и решение о его создании - всегда компромисс.
GoffmaniljyИнтересно, а как вы планируете отслеживать историю изменений, не сохраняя удаленный значения?
Например не удалять запись, а помечать удаленной. Но в принципе, если вы удалили запись, и сохранили все ее поля в журнале, не очень понятно, какую ценность здесь представляет именно суррогатный ID.
Помечать удаленной можно, но не всегда приемлемо - усложняются запросы, раздуваются таблицы-индексы и т.п. Как правило это используется как временная мера для повышение эффективности удаления.
Для суррогатного ИД чаще всего используется либо SEQUENCE, либо GUID, в обоих случаях можно принять неповторяемость его значений как приемлимое допущение. Соответственно существенно меньше шансов получить двойника некогда удаленной записи и путаницу в истории.
...
Рейтинг: 0 / 0
05.09.2011, 21:01
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37426081
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
GoffmanНапример не удалять запись, а помечать удаленной. Но в принципе, если вы удалили запись, и сохранили все ее поля в журнале, не очень понятно, какую ценность здесь представляет именно суррогатный ID.
Че-то я в предыдущем сообщении не о том подумал.
Суррогатный ПК здесь дает вот что: представьте, что у вас у одной из записей несколько раз менялся натуральный ключ. Как по журналу отследить, что речь все еще идет об одной и той же записи? Можно конечно писать старое значение натурального ПК вместе с новым (хотя для этого их надо сопоставить, и мы возвращаемся к проблеме с триггером), а как потом это собрать в один отчет? Тоже можно - рекурсивным запросом например. А для суррогатного неизменяемого ПК никаких подобных проблем даже не возникнет - всю историю изменений одной записи можно легко вытащить по этому значению.
...
Рейтинг: 0 / 0
05.09.2011, 21:37
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37426208
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljysphinx_mv4: Если уж Вы разрешить в БД изменение первичных ключей (любого типа) - лучше смотрите под ноги, куда наступаете...

У вас все хорошо? Повторяю еще раз - я в самом начале сказал , что проблема возникает именно при разрешении изменять первичные ключи.

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

Гениально! Вы не болгарин случайно? У них кивок головой отрицание означает, может вы по аналогии да и нет путаете? Я утверждаю, что приведенный мной код прекрасно сработает (докажете обратное? Без трепотни, а контрпримером?), и ограничения на данные я накладываю самые обычные (привязка к нескольким объектам, являющимся разными ветвями одной иерархии, встречается не так уж редко), и привожу вариант их реализации, который сервер не может реализовать автоматически из-за нарушения формальных завышеных требований (отсутствие множественных путей является одним из достаточных, но не необходимым условием корректности связей с каскадными действиями).

Ваш пример?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
CREATE TABLE TM (
IdM INT PRIMARY KEY
)
GO
CREATE TABLE TS (
IdS INT NOT NULL PRIMARY KEY,
IdM INT NULL ,
CONSTRAINT FK_TS_TM FOREIGN KEY (IdM) REFERENCES TM (IdM)
)
GO
INSERT TM VALUES ( 1 )
INSERT TM VALUES ( 2 )
INSERT TM VALUES ( 3 )
INSERT TM VALUES ( 4 )
INSERT TS VALUES ( 1 ,  1 )
INSERT TS VALUES ( 2 ,  2 )
INSERT TS VALUES ( 3 ,  3 )
INSERT TS VALUES ( 4 ,  4 )
GO
CREATE TRIGGER TU_TM ON TM
FOR UPDATE AS
UPDATE TS
SET IdM = i.IdM
FROM TS t1 JOIN deleted d ON t1.IdM = d.IdM LEFT JOIN inserted i ON  1 = 1 
GO
/* DML command */
UPDATE TM SET IdM =  5  WHERE IdM =  4
Вот и запустите его... О результатах не забудьте доложить...
Надеюсь, Вы НЕ получите message 547, level 16, state 1... Но это вряд ли...
iljysphinx_mvЕсли я напишу триггер для поддержания ссылочной целостности, Я перестану использовать декларативную ссылочную целостность на внешних ключах...
Госсподи, эту-то бредятину вы откуда выкопали??? Триггер для поддержания целостности частенько приходится использовать даже на неизменяющихся ключах, именно из-за ограничений на множественные каскады. В этом случае декларативная целостность поддерживается ключем ON DELETE NO ACTION, а каскадное удаление реализуется триггером BEFORE/INSTEAD OF.

Вы сами-то хоть поняли чего написали?
iljysphinx_mvНе хотелось бы расматривать клинические случаи, но когда кто-то начинает приводить примеры, четко подпадающие под ограничения конкретной технологии или платформы и при этом кричит "а оно не работает", это начинает вызывать весьма неоднозначные ассоциации.

Именно из-за НАЛИЧИЯ ПОТЕНЦИАЛЬНОЙ проблемы, связанной с удалением из таблицы А сервер и запрещает даже в Вашем примере использование для таблицы D нескольких внешних ключей с каскадным удалением - ЭТО ДЕЙСТВИТЕЛЬНО ТАК СЛОЖНО ПОНЯТЬ?!
Сколько эспрессии А простенько, без эмоций, взять и првести примерчик, когда наличие множественных связей действительно создает логически неразрешимую проблему при каскадном уделении/изменении вы можете? Или будем как заклинание читать мантру "раз это запрещено - значит так надо"?

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

К чему мне искать для Вас обобщенные случаи, если Вы даже в своих частных не особо разобрались?
iljysphinx_mvЗЫ. А Вы уже разобрались в естественных, суррогатных и составных ключах ?
Да вы шутник
Не более Вашего - " естественный ключ у вас тут напрашивается (car, part)" (с)...
...
Рейтинг: 0 / 0
06.09.2011, 00:42
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427520
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Какой вы скучный, все вам на пальцах надо разжевывать...
sphinx_mvПроблема НЕ возникает из-за разрешения изменений ПК - проблемы МОГУТ возникнуть. А могут и НЕ возникнуть...
И если проблема ВОЗНИКЛА - есть ВЕСЬМА существенная вероятность, что надо "что-то менять в консерватории", ака, в логике и структуре БД.
Да, и изменение должно заключаться в создании суррогатного неизменяемого ключа.
sphinx_mvВаш пример?
...
Вот и запустите его... О результатах не забудьте доложить...
Надеюсь, Вы НЕ получите message 547, level 16, state 1... Но это вряд ли...

Зашибись! А ничего, что я писал про INSTEAD OF триггер? И ах простите - я не ткнул вас носом, что приведенный код работает в ситуации, когда отсутствуют декларативные связи и поддержание целостности целиком возложено на триггеры. Хорошо, ткну сейчас. Естественно при наличии декларативной связи код триггера усложняется:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE TRIGGER TU_TM ON TM
instead of UPDATE AS
declare @t table(idS int primary key)

UPDATE TS
SET IdM = null
output deleted.idS into @t
FROM TS t1 JOIN deleted d ON t1.IdM = d.IdM

update TM
set idM = i.iDM
FROM TM t1 JOIN deleted d ON t1.IdM = d.IdM LEFT JOIN inserted i ON  1 = 1 

UPDATE TS
SET IdM = i.idM
FROM TS t1 JOIN @t t ON t1.IdS = t.IdS LEFT JOIN inserted i ON  1 = 1 
GO

sphinx_mviljyпропущено...
Госсподи, эту-то бредятину вы откуда выкопали??? Триггер для поддержания целостности частенько приходится использовать даже на неизменяющихся ключах, именно из-за ограничений на множественные каскады. В этом случае декларативная целостность поддерживается ключем ON DELETE NO ACTION, а каскадное удаление реализуется триггером BEFORE/INSTEAD OF.

Вы сами-то хоть поняли чего написали?

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

Если Вы такой умный, почему Вы не богатый?
А с чего вы взяли, что я не богатый????
sphinx_mvЕсли при удалении из таблицы A Вашего примера таблица D попадает под обработку, сколько по Вашему раз должны были бы сработать (сугубо теоретически) триггера (при их наличии) этой таблицы? Каскадные удаления по таблицам B и C не зависят друг от друга... Соответственно, и триггеры таблицы D имеют все шансы отработать (независимо) тоже два раза... По одним и тем же данным... Чего в этом случае будет стоить результат подобной обработки - на Ваше собственное усмотрение.
Это была попытка разумного объяснения (на пальцах)...

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

sphinx_mviljyпропущено...

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

К чему мне искать для Вас обобщенные случаи, если Вы даже в своих частных не особо разобрались?
Разобрался я в ваших частных. Хреновенькие они.

sphinx_mviljyпропущено...

Да вы шутник
Не более Вашего - " естественный ключ у вас тут напрашивается (car, part)" (с)...
Ну а кой же он тут? Вполне себе составной естественный ключ.
...
Рейтинг: 0 / 0
06.09.2011, 16:43
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427580
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyУдивлены?
А вот так... Запись таблицы это лишь способ хранения кортежа. Для кортежа не существует понятия "изменение". Кортеж с другими значениями "атрибутов" это уже дургой кортеж и никакой задачи "отслеживания истории конкретного кортежа" в рамках реляционной алгебры нет и быть не может. Конкретный кортеж всегда неизменен и лишь разные отношения (то бишь множества) либо включают его, либо не включают.
Как вы верно заметили алгебра оперирует множествами - то есть отслеживать можно только состояние множеств - временами одни элементы туда входят, другие удаляются, но никакой истории "элементов" нет.

С другой стороны можно реляционную алгебру рассматривать лишь как абстрактную теорию, а на практике оперировать запиясми, как объектами. В этом случае, несомненно можно обсуждать исторю жизни объекта, но тогда ваше утверждение "зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств" становится неверным.
Реляционная алгебра - эта математическая база логики реляционных СУБД. И на практике связке Отношение-Кортеж соответствует связка Таблица-Запись. Можно сколько угодно рассуждать на тему, что таблица - всего лишь способ хранения, но это не отменяет факта, что таблица - это множество записей. А так же того факта, что SQL - это декларативный язык, ориентированный на описание семантики операций над этими множествами. И для определения операции нам нужно определить условия над элементами множества - записями.
Что же касается истории - это действительно понятие другого порядка, она относится к записи как воплощению некоторого объекта предметной области. Вас смущает употребление в обоих случаях термина "запись"? Извините. Я не ставил целью формулировать логические теоремы, я рассуждал на весьма прикладном уровне и терминологию использовал простую, но устоявшуюся.
Чтобы мы могли отследить историю жизни конкретной записи-объекта, мы должны уметь находить и сопоставлять соответствующие записи-кортежи во множестве удаленных и добавленных. Но это ни коим образом не может нам помешать обрабатывать эти множества как множества (я имею ввиду задавать операции в терминах множеств, а не в терминах отдельных записей, т.е. курсор + цикл + построчная обработка).
Так хорошо?
...
Рейтинг: 0 / 0
06.09.2011, 17:06
| Ответить | Цитировать | Написать  
25 сообщений из 58, страница 2 из 3
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужен ли primary key в таблице, организующей связь один ко многим?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=37424692&tid=1542038]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 137ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 49ms
get tp. blocked users:
 1ms
others: 253ms
total:  475ms
созд. / загр.: 475ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]