|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Привет. Вопрос по каскадным обновлениям внешнего ключа. Структура БД: Таблица поставщиков: Код: sql 1. 2. 3. 4. 5. 6. 7.
Таблица продукции (обновляемый внешний ключ на поставщиков): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Таблица поставок продукции (обновляемый внешний ключ на поставщиков): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Таблица стоимости продукции в рамках поставок (обновляемый внешний ключ на поставки и продукцию): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Добавим данные: Код: sql 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. 28. 29. 30. 31. 32. 33. 34.
Ошибка в имени поставщика, пытаемся исправить 'ITNEL' на 'INTEL': Код: sql 1. 2. 3.
Ошибка: Код: powershell 1. 2. 3. 4. 5. 6.
Видимо, при последовательном обновлении одного из внешних ключей таблицы COSTS возникает "violation of FOREIGN KEY constraint" для другого внешнего ключа. Удаляем любой из внешних ключей (например, FK_COST_DELIVERY), обновляем поставщика, восстанавливаем внешний ключ: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Ошибок не возникает, внешний ключ накладывается. Скрипт воспроизведения: create table SUPPLIER ( SUPPLIER varchar( 10 ) not null ); alter table SUPPLIER add constraint PK_SUPPLIER primary key ( SUPPLIER ); create table PRODUCT ( SUPPLIER varchar( 10 ) not null, PRODUCT varchar( 10 ) not null ); alter table PRODUCT add constraint PK_PRODUCT primary key ( SUPPLIER, PRODUCT ); alter table PRODUCT add constraint FK_PRODUCT_SUPPLIER foreign key ( SUPPLIER ) references SUPPLIER ( SUPPLIER ) on update cascade; create table DELIVERY ( SUPPLIER varchar( 10 ) not null, DELIVERY_NO integer not null ); alter table DELIVERY add constraint PK_DELIVERY primary key ( SUPPLIER, DELIVERY_NO ); alter table DELIVERY add constraint FK_DELIVERY_SUPPLIER foreign key ( SUPPLIER ) references SUPPLIER ( SUPPLIER ) on update cascade; create table COST ( SUPPLIER varchar( 10 ) not null, PRODUCT varchar( 10 ) not null, DELIVERY_NO integer not null, PRICE float ); alter table COST add constraint PK_COST primary key ( DELIVERY_NO, PRODUCT, SUPPLIER ); alter table COST add constraint FK_COST_DELIVERY foreign key ( SUPPLIER, DELIVERY_NO ) references DELIVERY ( SUPPLIER, DELIVERY_NO ) on update cascade; alter table COST add constraint FK_COST_PRODUCT foreign key ( SUPPLIER, PRODUCT ) references PRODUCT ( SUPPLIER, PRODUCT ) on update cascade; insert into SUPPLIER ( SUPPLIER ) values ( 'ITNEL' ); insert into PRODUCT ( SUPPLIER, PRODUCT ) values ( 'ITNEL', 'PENTIUM-1' ); insert into PRODUCT ( SUPPLIER, PRODUCT ) values ( 'ITNEL', 'CORE I7' ); insert into DELIVERY ( SUPPLIER, DELIVERY_NO ) values ( 'ITNEL', 1 ); insert into COST ( SUPPLIER, PRODUCT, DELIVERY_NO, PRICE ) values ( 'ITNEL', 'PENTIUM-1', 1, 100 ); insert into COST ( SUPPLIER, PRODUCT, DELIVERY_NO, PRICE ) values ( 'ITNEL', 'CORE I7', 1, 280 ); commit; update SUPPLIER set SUPPLIER = 'INTEL' where SUPPLIER = 'ITNEL'; /* violation of FOREIGN KEY constraint "". violation of FOREIGN KEY constraint "FK_COST_DELIVERY" on table "COST". Foreign key reference target does not exist. Problematic key value is ("SUPPLIER" = 'INTEL', "DELIVERY_NO" = 1). At trigger 'CHECK_4' At trigger 'CHECK_1'. */ alter table COST add drop FK_COST_DELIVERY; update SUPPLIER set SUPPLIER = 'INTEL' where SUPPLIER = 'ITNEL'; alter table COST add constraint FK_COST_DELIVERY foreign key ( SUPPLIER, DELIVERY_NO ) references DELIVERY ( SUPPLIER, DELIVERY_NO ) on update cascade; Вопрос: это ошибка каскадного обновления внешних ключей или кривая структура БД? Если кривая структура БД, какой структурой можно обеспечить каскадное обновление внешних ключей? С уважением, Poleosv. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 11:19 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovЕсли кривая структура БД, какой структурой можно обеспечить каскадное обновление внешних ключей?Если в принципе требуется каскадный апдейт ключей - такая структура никуда не годится. Первичный ключ не должен нести на себе никаких других функций, кроме ключа, никаких названий, намеков, ИНН-ов и прочей ерунды. Ключ это просто 64 битной число - идентификатор. Его апдейтить не надо ни при каких обстоятельствах. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 11:43 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Ivan_PisarevskyЕсли в принципе требуется каскадный апдейт ключей - такая структура никуда не годится. Понятно, в такой структуре исправление ошибки э-э-э ... весьма затруднительно. Заменим primary key на unique not null - смена шила на мыло? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 11:54 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesovсмена шила на мыло? Вовсе нет. Но вопрос остается открытым - каскадное обновление внешних ключей на некоторых структурах не возможно? P.S. Вопрос прямоты/кривизны структуры не рассматривается. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 11:59 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesov, бывают случаи, что так увлекаются каскадами, что зацикливают каскадные ФК, например на удаление. Эффект потрясающий - удаляем одну запись, и в результате удаляется почти ВСЁ. Сам вопрос про каскадные ключи, конечно, интересный, но так не делают, потому что - в реальной БД изменение одного значения в SUPPLIER приводит к каскадному апдейту миллионов записей в разных таблицах - потому естественные ПК и не используют. Абстрактный ПК нет смысла изменять, потому что он ничего не значит. А следовательно, необходимость в каскадном обновлении отпадает. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 12:39 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesov, собственно, ошибка структуры в том, что COST ссылается на ДВЕ таблицы, которые зависят от SUPPLIER, и при каскадном обновлении от SUPPLIER не могут быть обновлены ОДНОВРЕМЕННО. Так что тут нет ошибки с ФК, есть ошибка структуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 12:47 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvбывают случаи, что так увлекаются каскадами Вопрос не про излишнее увлечение каскадными обновлениями, а про факт возникновения ошибки при каскадном обновлении внешних ключей. P.S. Вопрос - при использовании некой фичи FB возникает ошибка. Ответ - не используй эту фичу. (!!!!!!!) Народ, вопрос не про ошибки в структуре БД, а про ошибки FB. Feel difference, какгриться. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 12:48 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvCOST ссылается на ДВЕ таблицы, которые зависят от SUPPLIER FB каскадное обновление таки внешних ключей не поддерживает? Это отображено где-нибудь в документации? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 12:53 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovFB каскадное обновление таки внешних ключей не поддерживает? а кто поддерживает? Что значит "поддерживает"? Я вот тебя спрашиваю - как ты обновишь две таблицы одновременно? Или как - парсер должен отвергать второй ФК на таблицу COST, потому что парсер обнаружит ссылку на одну и ту же таблицу через 2 косвенных ФК? А через 3 ФК? С точки зрения ФК вообще - он построен нормальным образом. Другое дело, что ты связал таблицы таким образом, что каскадное обновление ФК в данном случае приводит к ошибке. PolesovЭто отображено где-нибудь в документации? мне интересно, каким образом это может или должно быть отражено. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:37 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvмне интересно, каким образом...Понятно - не используй эту фичу. Я думаю, ответ на этот вопрос могут дать только разработчики. Все остальные - от лукавого. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:41 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovНарод, вопрос не про ошибки в структуре БД, а про ошибки FB. это не ошибка ФБ. ФК в данном случае отрабатываются поочередно. Потому что это "системные триггеры". Если на таблице 5 триггеров, то они не срабатывают все одновременно. Они отрабатывают по одному. Да, у ФБ вот такая реализация. Ты напоролся на нее. PolesovОтвет - не используй эту фичу. да, потому что в такой схеме, которую ты построил, так - не работает. Даже если бы работало, у тебя все равно, с моей точки зрения, ФК с COST неправильные. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:42 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvс моей точки зрения, ФК с COST неправильные Polesovкакой структурой можно обеспечить каскадное обновление внешних ключей? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:44 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Каскадные ФК - зло. Их не надо использовать нигде и никогда. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:49 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovКаскадные ФК - зло. Их не надо использовать нигде и никогда. Я бы не рискнул так заявить моему начальнику. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:55 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesov, у вас "ромб": таблица cost будет обноалвять двумя каскадами. В ФБ такой DDL молча пропускается и проблемы лезут позже, а вот в m$ sql - облом сразу . В общем, это скорее не ошибка, а особенность реализации СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 13:55 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Да кто его разберёт...В ФБ такой DDL молча пропускается и проблемы лезут позжеАпчемиречь... Да кто его разберёт...В общем, это скорее не ошибка, а особенность реализации СУБД.Понятно, что можно изменить структуру БД (суррогатный PK + not null unique по наименованию), но в случае с естественным PK ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:01 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovЯ бы не рискнул так заявить моему начальнику. Твоя трусость - твоя проблема. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:01 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Да кто его разберёт... http://www.sql.ru/forum/899636/introducing-foreign-key-constraint-on-table-may-cause-cycles-or-multiple-cascade-paths Хороший вопрос: Ex_SoftЭто M$ SQL такую структуру штатными средствами одолеть не может или вопрос плавно переходит в Проектирование БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:08 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТвоя трусость - твоя проблема. Предлагаешь сменить меcто работы, храбрец? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:09 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovЯ бы не рискнул так заявить моему начальнику. хочешь, я рискну? Собственно, я уже сказал - 21181802 к тому же, MS SQL сразу посылает с такой хренью. 21181894 PolesovПонятно, что можно изменить структуру БД (суррогатный PK + not null unique по наименованию), но в случае с естественным PK да не использует никто естественные ПК в здравом уме. Разве что те, кто еще не напоролся на проблемы "начальной школы проектирования БД". http://www.ibase.ru/natural-keys-versus-atrificial-keys-by-tentser/ https://habrahabr.ru/company/oleg-bunin/blog/348172/#choice И правило тут простое - если значение столбца может со временем меняться, то это уже не ПК. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:10 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvда не использует никто естественные ПК Можно ли сказать, что в системных таблицах FB поля RDB$RELATION_NAME, RDB$FIELD_NAME являются суррогатными, а не естественными ключами? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:14 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesovnot null unique по наименованию Все нубы стремятся наложить ограничение уникальности на название, имя и т.п. С опытом эксплуатации таких систем приходит понимание, что это плохая идея и в реальности не работает. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:14 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Структура БД неверна, грубо говоря, в корне. Если субъект (поставщик, клиент и т.п.) имеет цифровое имя (код) и он может изменяться, это имя должно быть представлено отдельным полем. Его использование в качестве ФК совершенно не нужно. Внутренний же идентификатор субъекта обычно является первичным ключом (AUTOINCREMENT) и никогда не модифицируется. Поэтому все ФК на него не должны быть UPDATE, только DELETE. С DELETE тоже есть масса нюансов, но это уже другая песня... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:15 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovПредлагаешь сменить меcто работы, храбрец? Предлагаю разобраться: кто именно проектирует БД - ты или начальник. Если начальник, то почему на форуме ты а не он? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:16 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovPolesovnot null unique по наименованию Все нубы стремятся наложить ограничение уникальности на название, имя и т.п. С опытом эксплуатации таких систем приходит понимание, что это плохая идея и в реальности не работает. Ну, сказать, что "все нубы..." Тогда уж озвучь, как правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:16 |
|
|
start [/forum/topic.php?fid=40&msg=39599980&tid=1561239]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 168ms |
0 / 0 |