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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE `test` (
  `car` int( 11 ) NOT NULL,
  `part` int( 11 ) NOT NULL,
  `level` int( 11 ) NOT NULL,
  `params` text COLLATE utf8_unicode_ci NOT NULL,
  KEY `car` (`car`)
)

Нужно ли в этой таблице поле id (primary key) ?

Выборки происходят по полю car
Апдейты по car и part
...
Рейтинг: 0 / 0
24.08.2011, 15:45
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410099
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Sozonov,

нужен ли в таблице суррогатный ключ - знать никто кроме вас не может. Естественный ключ у вас тут напрашивается (car, part).
...
Рейтинг: 0 / 0
24.08.2011, 16:20
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410133
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 24.08.2011 16:45, Sozonov wrote:

PK нужен в любой таблице.

> Нужно ли в этой таблице поле id (primary key) ?

Если на эту таблицу-связку не ссылаются другие таблицы,
то отдельный суррогатный ключ в таких таблицах точно не нужен.
Если на таблицу-связку есть ссылки, то можно подумать о том,
чтобы его добавить, т.е. он может быть нужен, а может быть и
нет. Зависит это от того, сколько таблиц ссылается на данную,
чем больше, тем более он нужен (больше экономия).
Но допустимы оба варианта дизайна.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
24.08.2011, 16:34
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410153
Фотография Светлый_Дайвер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Светлый_Дайвер
Участник
MasterZiv
PK нужен в любой таблице.



Не правда.

2Sozonov
Это твоя таблица test таблица связывающая машину и её части - так?
Причем запчастей одних и тех же может быть куча, так как отсутствует поле count.
Стало быть здесь всякие PK/AK никому не нужны.

А вот про индексы подумать нужно...
...
Рейтинг: 0 / 0
24.08.2011, 16:45
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410194
Sozonov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sozonov
Гость
Светлый_Дайвер
Не правда.

2Sozonov
Это твоя таблица test таблица связывающая машину и её части - так?
Причем запчастей одних и тех же может быть куча, так как отсутствует поле count.
Стало быть здесь всякие PK/AK никому не нужны.

А вот про индексы подумать нужно...

Да, эта таблица связывает машины и запчасти.
Каждой машине соответствует несколько запчастей (записи из таблицы parts), но у авто всегда одна запчасть каждого типа.
Иначе говоря: у каждой машины по 11 запчастей, разный только уровень запчасти (поле level ) и некоторые запчасти имеют специфические параметры (поле params )

По индексам:
Выборка из таблицы идет всегда по полю car , т.е.
Код: plaintext
SELECT `part`, `level`, `params` FROM `test` WHERE `car` =  12892
Удаления очень редки и происходят тоже только по полю car .
По UPDATE `ам: они проходят по полям `car` и `part` :
Код: plaintext
UPDATE `test` SET `level` =  3 , `params` = 'some params' WHERE `car`=  3123  AND `part` =  7

В данный момент создан только индекс по полю car .
Прочел недавно, что у индексов используется левая часть, т.е. индекс (`car`, `part`) будет использован при запросе
Код: plaintext
SELECT `part`, `level`, `params` FROM `test` WHERE `car` =  12892
Это верно?
Если это так, то действительно лучше создать индекс (`car`, `part`), тогда он поможет также про update.

Прав ли я?
...
Рейтинг: 0 / 0
24.08.2011, 17:03
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410222
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Sozonov,

да. Сделайте (car,part) первичным кластерным ключем и не мучьте животное.
...
Рейтинг: 0 / 0
24.08.2011, 17:18
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410501
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
Sozonov,

если собираешься ссылаться на эту таблицу, тогда да, иначе нет смысла
...
Рейтинг: 0 / 0
24.08.2011, 20:19
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37410749
Kyubee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kyubee
Участник
Нужно. Нехорошо, когда pk меняется (и вообще, когда несёт какую-то дополнительную нагрузку кроме идентификации записи)
...
Рейтинг: 0 / 0
25.08.2011, 00:00
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37423351
BVB_berserk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BVB_berserk
Гость
Не применительно именно к данной задаче, но в общем случае, одна запчасть может подходить на несколько машин.
Поэтому я бы организовал отдельно таблицу "cars", отдельно "parts", и третью связывающую таблицу, организующую связь "многих-ко-многим".
...
Рейтинг: 0 / 0
02.09.2011, 17:32
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37423353
BVB_berserk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BVB_berserk
Гость
Тогда в первой таблице PK - CarID, во второй таблице PK - PartID, в третьей таблице PK - (CarID,PartID), чтобы исключить дублирование записей.
...
Рейтинг: 0 / 0
02.09.2011, 17:33
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37423670
Flying Dutchman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Flying Dutchman
Участник
MasterZivOn 24.08.2011 16:45, Sozonov wrote:

PK нужен в любой таблице.


Я бы сказал "почти в любой". Как редкое исключение, на ум приходит таблица для временного хранения (staging area) для данных с плохим качеством, которые потом "очищаются" и записываются в основную БД.
...
Рейтинг: 0 / 0
03.09.2011, 00:38
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37423811
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
тут 2 определяющих фактора для создания суррогатного PK:

- если есть ссылки на данную таблицу из других таблиц
- собираетесь ли в приложении редактировать записи из этой таблицы

если есть хоть один из факторов - необходим суррогатный PK
...
Рейтинг: 0 / 0
03.09.2011, 13:12
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37423950
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
spтут 2 определяющих фактора для создания суррогатного PK:

- если есть ссылки на данную таблицу из других таблиц
- собираетесь ли в приложении редактировать записи из этой таблицы

если есть хоть один из факторов - необходим суррогатный PK
Оба утверждения очень спорны. Ссылки вполне себе могут проходить и по естественному ключу, если он небольшой, а редактирование записей вовсе не означает изменения ПК. По сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.
...
Рейтинг: 0 / 0
03.09.2011, 16:47
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424073
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljyПо сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Каких именно заморочек?
Просто я не раз сталкивался со сменой PK с естественного на суррогатный, особых проблем не припомню.
...
Рейтинг: 0 / 0
03.09.2011, 19:51
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424079
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
GoffmaniljyПо сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Каких именно заморочек?
Просто я не раз сталкивался со сменой PK с естественного на суррогатный, особых проблем не припомню.
Я имею ввиду заморочки при работе с изменяющимся естественным ключем.
...
Рейтинг: 0 / 0
03.09.2011, 20:05
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424114
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljy,

ну так что за заморочки то?
...
Рейтинг: 0 / 0
03.09.2011, 20:54
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424131
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Goffmaniljy,

ну так что за заморочки то?
Необходимость каскадных изменений зависимых таблиц при изменении ПК. Проблемы при изменении ПК пользователем. Проблемы в триггерах при сопоставлении inserted-deleted. Вот навскидку.
...
Рейтинг: 0 / 0
03.09.2011, 21:13
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424421
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
в триггерах доступно и новое и старое значение, да и в таких кросс-таблицах обычно триггеров не делают.
получается, что проблемы могут быть, только когда на эту таблицу кто-то ссылается?
...
Рейтинг: 0 / 0
04.09.2011, 10:38
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424450
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
iljyОба утверждения очень спорны. Ссылки вполне себе могут проходить и по естественному ключу, если он небольшой, а редактирование записей вовсе не означает изменения ПК. По сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Конечно они могут быть спорны если все время изобретать велосипед, но данные факторы для создания PK выработаны из широкой практики. И понятное дело если вы мучаетесь с каждым объектом базы данных снова и снова - без фреймворков - то конечно можно при редактировании сущности и работать с составным ключом из 5 - 10 полей - никто этого не запретит! :))
...
Рейтинг: 0 / 0
04.09.2011, 12:06
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424460
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Goffmanв триггерах доступно и новое и старое значение, да и в таких кросс-таблицах обычно триггеров не делают.
И что? Как вы узнаете, какая строка какой соответствует? И, во-первых, натуральные ПК бывают не только на кросс-таблицах, а во-вторых - триггеры часто используются даже на них для поддержания целостности.
Goffmanполучается, что проблемы могут быть, только когда на эту таблицу кто-то ссылается?
Проблемы возникают, когда вам нужно отследить изменения записи. Причем как раз проблемы со ссылками и пользовательскими изменениями решаются (ссылки автоматически изменяются движком сервера, а клиент вполне может сохранять старые значения ПК и обращаться к записи по ним), а вот с триггером - увы. Еще пример - журналирование изменений.
...
Рейтинг: 0 / 0
04.09.2011, 12:33
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424464
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
spiljyОба утверждения очень спорны. Ссылки вполне себе могут проходить и по естественному ключу, если он небольшой, а редактирование записей вовсе не означает изменения ПК. По сути, единственное очень и очень существенное пожелание к ПК - это то, что он не должен меняться, иначе возникает изрядное количество заморочек.

Конечно они могут быть спорны если все время изобретать велосипед, но данные факторы для создания PK выработаны из широкой практики. И понятное дело если вы мучаетесь с каждым объектом базы данных снова и снова - без фреймворков - то конечно можно при редактировании сущности и работать с составным ключом из 5 - 10 полей - никто этого не запретит! :))
Мучаются те, кто потом пытается оптимизировать базы, созданные теми самыми фреймворками. Вот, например, прелестная вещь - гуид, очень удобно - уникальность гарантирована (вроде бы), получать легче легкого даже на клиенте, самому ничего отслеживать не надо, напихал в каждую таблицу и радуешься. А всякие ДБА - идиоты, говорят про какую-то фрагментацию, раздувание индексов и прочую никому не нужную хрень.
...
Рейтинг: 0 / 0
04.09.2011, 12:45
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424476
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljyИ что? Как вы узнаете, какая строка какой соответствует?
Запросто, помогут :new или :old


iljyИ, во-первых, натуральные ПК бывают не только на кросс-таблицах,
Просто тема именно про кросс таблицы.

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


iljyЕще пример - журналирование изменений.
частный случай ссылочной целостности.
...
Рейтинг: 0 / 0
04.09.2011, 13:19
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424533
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
GoffmaniljyИ что? Как вы узнаете, какая строка какой соответствует?
Запросто, помогут :new или :old
Несомненно, вот только они доступны только в триггерах FOR EACH ROW, а они есть далеко не во всех СУБД.
GoffmaniljyИ, во-первых, натуральные ПК бывают не только на кросс-таблицах,
Просто тема именно про кросс таблицы.
Вы меня спрашивали про возможные проблемы с естественным ПК. На данной конкретной теме с ним никаких проблем нет, о чем я уже давным-давно сказал .
Goffmaniljyа во-вторых - триггеры часто используются даже на них для поддержания целостности.
Насчет часто, это вы преувеличили, и опять же, какую проблему решит именно суррогатный PK в данном случае - не раскрыли.

Да ну? Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее, и СУБД тупо не дает задать для них ON DELETE CASCADE, и приходится реализовывать эту функциональность триггерами? По поводу "какую проблему" смотрите выше.
GoffmaniljyЕще пример - журналирование изменений.
частный случай ссылочной целостности.
эээээ.... Какая связь между ведением журнала изменений, с указанием кто и когда изменил запись, и ссылочной целостностью?? А неизменяемый ПК здесь нужен именно для того, чтоб надежно отследить историю изменений конкретной записи, для чего ее нужно однозначно идентифицировать все время ее жизни.
...
Рейтинг: 0 / 0
04.09.2011, 15:43
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424666
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
iljyНесомненно, вот только они доступны только в триггерах FOR EACH ROW, а они есть далеко не во всех СУБД.
а вы имели в виду триггеры STATEMENT, так в них принципиально нельзя достучаться до конкретной записи, по крайней мере в Oracle.


iljy... Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее...
Необходимость каскадных изменений и удалений, как я понимаю, может возникать только если на этот ключ есть ссылка из других таблиц, или еще есть варианты?

iljyэээээ.... Какая связь между ведением журнала изменений, с указанием кто и когда изменил запись, и ссылочной целостностью??
Потому что таблица журнала в этом варианте ссылается на таблицу с данными, надежнее всего это сделать с помощью внешнего ключа, или не так?
...
Рейтинг: 0 / 0
04.09.2011, 20:10
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37424667
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljyGoffmanпропущено...

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

FOR EACH ROW (с новыми и старыми значениями) весьма несложным образом "эмулируется" даже на весьма "древних" версиях MSSQL.
iljyGoffmanпропущено...
Насчет часто, это вы преувеличили, и опять же, какую проблему решит именно суррогатный PK в данном случае - не раскрыли.

Да ну? Знаете, что такое каскадное удаление и изменение? А знаете, что при наличии нескольких ВК могут вызникать множественные зависимости и прочее, и СУБД тупо не дает задать для них ON DELETE CASCADE, и приходится реализовывать эту функциональность триггерами? По поводу "какую проблему" смотрите выше.
При каскадных удалениях и обновлениях не должно возникать циклических зависимостей в операциях.
Соответственно, никакой разницы между естественными и суррогатными ключами в данном случае нет.
...
Рейтинг: 0 / 0
04.09.2011, 20:12
| Ответить | Цитировать | Написать  
Нужен ли 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
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427618
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
iljyТак хорошо?
Замечательно.
Итак, вы согласны с тем, что "отслеживание истории записей" никакого отношения к SQL не имеет, а является "понятием другого порядка".
Собственно тут и кроется причина противоречий в вашем утверждении после которого я влез в дискуссию:
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств. Но для правильного сопоставления двух множеств inserted и deleted необходим неизменяющийся уникальный ключ, одноpначно идентифицирующий запись.
Если вы ссылаетесь на "скуль", то никаких задач по "однозначной идентификации записей" не встает. А если вы оперируете "понятиями другого порядка", то задача о "достукивании в триггере до конкретной записи" вполне себе правильная.

Но вернувшись к теме топика можно заметить, что речь идет о таблице связей. Записи этой таблицы вряд ли можно рассматривать "воплощению некоторого объекта предметной области".
...
Рейтинг: 0 / 0
06.09.2011, 17:22
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427641
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
Bogdanov AndreyСобственно тут и кроется причина противоречий в вашем утверждении после которого я влез в дискуссию:
iljyНе очень понятно, зачем в триггере достукиваться до конкретной записи, скуль - язык обработки множеств. Но для правильного сопоставления двух множеств inserted и deleted необходим неизменяющийся уникальный ключ, одноpначно идентифицирующий запись.
Если вы ссылаетесь на "скуль", то никаких задач по "однозначной идентификации записей" не встает. А если вы оперируете "понятиями другого порядка", то задача о "достукивании в триггере до конкретной записи" вполне себе правильная.

Извините, но видно что вы теоретик Под "достукиванием до конкретной записи" обычно понимается позаписная обработка в цикле. И именно это вступает в противоречие с декларативной природой скуля. А для множественной обработки, позволяющей нам тем или иным способом отследить историю изменений записи-объекта, нужно иметь способ сопоставления записей-кортежей в множествах inserted-deleted.
Bogdanov AndreyНо вернувшись к теме топика можно заметить, что речь идет о таблице связей. Записи этой таблицы вряд ли можно рассматривать "воплощению некоторого объекта предметной области".
Во-первых, здесь не совсем таблица связей: в ней явно больше 2х полей, так что это скорее не связь, а подчиненный объект Запчасть-Автомобиля, являющийся конкретизацией объекта Запчасть. Но тут пусть ТС сам решает, я всей структуры не вижу.
Ну а во-вторых - то мое утверждение уже вышло за рамки топика, меня попросили сказать, какие потенциальные проблемы в принципе могут возникнуть при разрешении изменять ПК.
...
Рейтинг: 0 / 0
06.09.2011, 17:34
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427824
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljyКакой вы скучный, все вам на пальцах надо разжевывать...
sphinx_mvПроблема НЕ возникает из-за разрешения изменений ПК - проблемы МОГУТ возникнуть. А могут и НЕ возникнуть...
И если проблема ВОЗНИКЛА - есть ВЕСЬМА существенная вероятность, что надо "что-то менять в консерватории", ака, в логике и структуре БД.
Да, и изменение должно заключаться в создании суррогатного неизменяемого ключа.

Ваша проблема в том, что Вы требуете этого независимо от задачи...
При этом, вроде бы, соглашаясь, что ЕСТЬ много задач, которые ПРЕКРАСНО могут жить даже с изменяемым естественным ключом.
iljysphinx_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

И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"...
...
Рейтинг: 0 / 0
06.09.2011, 18:45
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37427914
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mviljyКакой вы скучный, все вам на пальцах надо разжевывать...
пропущено...

Да, и изменение должно заключаться в создании суррогатного неизменяемого ключа.

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

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

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

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

Какие взаимные блокировки в рамках одной сессии? Кто с кем за что будет бороться? Или вы про распараллеливание решили поговорить? Так оно при каскадных операциях обычно запрещено ( Restrictions on Parallel DML ).
sphinx_mvИ что Вы уперлись в INSTEAD OF? Разве Вы не в курсе, что есть еще и другие типы триггеров, которых в отличие от INSTEAD OF может даже быть больше одного на каждый вид операции?
А вы разве не в курсе, что реализовать каскадное удаление/изменение при наличии декларативного ограничения вида FOREIGN KEY ... ON DELETE/UPDATE NO ACTION можно только INSTEAD OF/BEFORE триггером? Ну значит теперь будете.
А при каскадах INSTEAD OF триггеры запрещены (я об этом сказал), так что мы однозначно говорим о проблемах при наличии AFTER-триггеров (простите, что забыл сказать об этом явно большими буквами ).
sphinx_mviljyпропущено...

Разобрался я в ваших частных. Хреновенькие они.

Тут, скорее, Вы хреновенько разобрались... Но, "в общем случае" это излечимо...

Хоть бы одним глазком на "Тот Самый Общий Случай" взглянуть...
sphinx_mviljyпропущено...

Ну а кой же он тут? Вполне себе составной естественный ключ.
Вы вообще с декларацией этих полей в таблице успели ознакомиться?
Чего-то я как-то не припомню (из реальной жизни) ни автомобиля "1", ни гайки "10"...
Видите ли в чем дело... Вспомните, Ваше Высочество, ведь
Суррога́тный ключ — это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого — служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД, а генерируется искусственно.. Так что Вы безусловно абсолютно точно и полно подметили, что ключи car и part являются несомненно суррогатными для таблиц Автомобили и Запчасти. Но позволю себе нижайше обратить Ваше просвященное внимание на то, что для таблицы test эти поля являются информационными, поскольку наверняка (это допущение, основанное на предположениях о предметной области ТС, но я смею надеяться, что Ваш беспристрастный взгляд сочтет сие допущение имеющим право на существование) ссылаются на соответствующие поля таблиц Автомобиль и Запчасти соответственно. Следствием же этого является тривиальный факт, что ключ, образованный этими полями, никак не может быть суррогатным.
...
Рейтинг: 0 / 0
06.09.2011, 20:05
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37428149
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
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 эти поля являются информационными, поскольку наверняка (это допущение, основанное на предположениях о предметной области ТС, но я смею надеяться, что Ваш беспристрастный взгляд сочтет сие допущение имеющим право на существование) ссылаются на соответствующие поля таблиц Автомобиль и Запчасти соответственно. Следствием же этого является тривиальный факт, что ключ, образованный этими полями, никак не может быть суррогатным.
Составной ключ на основе суррогатных полей быть "естественным" никак не может... По очень простой причине - ну, не несет он непосредственной полезной информационной нагрузки ни из какой предметной области... Это так, к сведению...
...
Рейтинг: 0 / 0
07.09.2011, 01:35
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37428628
iljy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iljy
Участник
sphinx_mviljyпропущено...

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

У Вас мысли отличаются от того, что вы пишите: не Вы ли писали, что ПК не должен меняться? Кто и какого это запретил?!
И не Вы ли писали, что "проблемы возникают" (даже без всяких "иногда", кстати)? А они всего лишь МОГУТ ИНОГДА возникнуть...
Даже некоторое увеличение нагрузки при обновлении связанных таблиц, увеличение занимаемого базой дискового пространства и усложнение синтаксиса запросов очень не всегда становятся проблемой...
Вы читать вообще умеете? Может шрифт мелковат?
iljyнеизменяемость - "очень и очень существенное пожелание к ПК"

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

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

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

sphinx_mvВы уж определитесь - Вам шашечки или ехать?
Еще чуть-чуть, и Вы начнете требовать отмены использования хранимых процедур и заставлять выполнять всю обработку данных на клиенте...
... или флудят.

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

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

Очччееень умнО! Это просто пять!
Какое, простите, отношение Oracle имеет к MSSQL?
Позвольте обратить Ваше просвещенное внимание на постенький факт: MSSQL до сих пор не умеет распараллеливать DML-операции. А когда научится (хотя по-моему даже в Denali этого не обещают) - решение проблемы каскадов можно слизнуть из оракла.
sphinx_mvМожет тогда Вы нам расскажете про мутации таблиц на Oracle?.. И про "тривиальность" их обхода?..Ну уж это-то вы к чему приплели? Умным словом сверкнуть решили от безысходности? Проблема мутации таблиц (она же ошибка ORA-04091) возникает при обращении из ROW-level триггера к изменяющейся таблице. Один из вариантов решения - симуляция STATEMENT-триггеров с помощью явного создания таблиц inserted-deleted в качестве переменных пакета.
sphinx_mviljyпропущено...

А вы разве не в курсе, что реализовать каскадное удаление/изменение при наличии декларативного ограничения вида FOREIGN KEY ... ON DELETE/UPDATE NO ACTION можно только INSTEAD OF/BEFORE триггером? Ну значит теперь будете.

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

Безусловно бредятина. Не вижу ни одной причины отказываться от декларирования ВК только из-за невозможности написать ON DELETE CASCADE. При этом в схеме базы сохраняется явно прописанная логическая связь, движок СУБД обеспечивает практически всю функциональность ВК, а недостающую (и только недостающую, а не весь комплект) я дописываю простеньким триггером.

sphinx_mviljyА при каскадах INSTEAD OF триггеры запрещены (я об этом сказал), так что мы однозначно говорим о проблемах при наличии AFTER-триггеров (простите, что забыл сказать об этом явно большими буквами ).

Если Вы не знаете как запустить триггер INSTEAD OF в рамкак каскадной операции, это совершенно не значит, что такие триггеры ЗАПРЕЩЕНЫ. Но это так... К слову, пришлось...
iljyпропущено...

Вы фееричны Прочитайте наконец документацию
http://msdn.microsoft.com/en-us/library/ms189799.aspx For INSTEAD OF triggers, the DELETE option is not allowed on tables that have a referential relationship specifying a cascade action ON DELETE. Similarly, the UPDATE option is not allowed on tables that have a referential relationship specifying a cascade action ON UPDATE.
Специально для Вас напишу большими буквами - я говорю про наличие формального ограничения, а не про способы его обхода.

sphinx_mvВидите ли в чем дело... Вспомните, Ваше Высочество, ведь
пропущено...
. Так что Вы безусловно абсолютно точно и полно подметили, что ключи car и part являются несомненно суррогатными для таблиц Автомобили и Запчасти. Но позволю себе нижайше обратить Ваше просвященное внимание на то, что для таблицы test эти поля являются информационными, поскольку наверняка (это допущение, основанное на предположениях о предметной области ТС, но я смею надеяться, что Ваш беспристрастный взгляд сочтет сие допущение имеющим право на существование) ссылаются на соответствующие поля таблиц Автомобиль и Запчасти соответственно. Следствием же этого является тривиальный факт, что ключ, образованный этими полями, никак не может быть суррогатным.
Составной ключ на основе суррогатных полей быть "естественным" никак не может... По очень простой причине - ну, не несет он непосредственной полезной информационной нагрузки ни из какой предметной области... Это так, к сведению...
Для тех кто в танке - повторяем нашу передачу:
Суррога́тный ключ — это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого — служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД , а генерируется искусственно.
На всякий случай персонально для Вас уточню - первичные ключи других таблиц являются какими-либо другими данными из БД.
...
Рейтинг: 0 / 0
07.09.2011, 11:36
| Ответить | Цитировать | Написать  
Нужен ли primary key в таблице, организующей связь один ко многим?
    #37429424
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
iljysphinx_mvпропущено...
После того, как Вы с пеной у рта утверждали, что неработающий в обсуждаемых условиях код обязательно будет работать - мне от этого сугубо... Одним "гениальным" (censored) больше... одним меньше... Я их уже столько повидал...
Когда нечего сказать по существу - цепляются к формальностям...

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

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

Когда нечего сказать по существу - цепляются к формальностям...

Неслабая такая формальность - предъявление претензий к НЕРАБОТАЮЩЕМУ фрагменту кода...

К работающему, просто без явной оговорки очевидно необходимых для его работы условий. Так что увы и ах - вы цепляетесь за соломинку.
sphinx_mviljyпропущено...Позвольте обратить Ваше просвещенное внимание на постенький факт: MSSQL до сих пор не умеет распараллеливать DML-операции. А когда научится (хотя по-моему даже в Denali этого не обещают) - решение проблемы каскадов можно слизнуть из оракла.

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

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

Для тех кто в танке - повторяем нашу передачу:
пропущено...

На всякий случай персонально для Вас уточню - первичные ключи других таблиц являются какими-либо другими данными из БД.
И где же Вам такую траву продают-то?
Что, красавица, и сказать-то по существу больше нечего?
...
Рейтинг: 0 / 0
07.09.2011, 18:09
| Ответить | Цитировать | Написать  
58 сообщений из 58, показаны все 3 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужен ли primary key в таблице, организующей связь один ко многим?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1542038]:
 0ms
get settings:
 4ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 260ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 64ms
get tp. blocked users:
 1ms
others: 215ms
total:  568ms
созд. / загр.: 568ms
x
x
Закрыть


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