|
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 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПредлагаю разобраться: кто именно проектирует БД - ты или начальник Начальник проектирует не во всех случаях, но вот каскадные FK для него - святое. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:20 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovТогда уж озвучь, как правильно. Ограничение уникальности в данном случае не нужно. В лучшем случае его все будут тупо обходить, в худшем - оно создаст проблемы и опять же его придётся обходить. PolesovНачальник проектирует не во всех случаях, но вот каскадные FK для него - святое. Раз "он начальник, ты дурак", то твоё дело маленькое - доложить ему о возникшей проблеме и запросить инструкции по дальнейшему поведению. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:24 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Ребята, вопрос был не о правильности структуры, а об ошибке каскадного обновления FK. Выяснилось, что каскадное обновление такого FK технически не возможною В принципе, тему можно считать закрытой. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:24 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovМожно ли сказать, что в системных таблицах FB поля RDB$RELATION_NAME, RDB$FIELD_NAME являются суррогатными, а не естественными ключами? Нет. Это АЛЬТЕРНАТИВНЫЙ ключ. Кроме того, не надо воспринимать структуру метаданных ФБ как образец для подражания. Между прочим, там констрейнтов вообще нет. Там есть только индексы, уникальные или нет. Тем не менее, у RDB$RELATIONS есть RDB$RELATION_ID. В общем, бывают БД без constraints. Редкий случай, но в таких системах целостность поддерживает нечто вроде трехзвенки, центрального сервера. В случае ФБ сам ФБ и есть этот "центральный сервер" для поддержки целостности в RDB$. Конечно, можно было бы переделать эту структуру "красиво", но она была создана в середине 80х годов, и как я уже сказал выше, это не совсем прикладная модель БД. Если вернуться к каскадным обновлениям, то, как уже было сказано - каскадные обновления зло, но зло косвенное, возникающее из-за применения естественных ключей - естественные ключи - зло, потому что могут меняться, ухудшают производительность, вынуждают использовать каскадные ФК, и т.д. Так что, первопричина проблем в данном случае - естественные ключи. О чем, как бы, пережевано уже лет тридцать. Если твой шеф (или еще кто-то) считает, что ЕК - это нормально (и вследствие - за каскадные обновления), то это просто означает, что он никогда не проектировал прикладные БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:26 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvТак что, первопричина проблем в данном случае - естественные ключи Да кто бы с этим спорил. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:28 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovРебята, вопрос был не о правильности структуры, а об ошибке каскадного обновления FK. да ё-мое. То есть, выходит, ФБ плохой, MS SQL плохой, а наша структура - хорошая? Ошибка - это следствие кривости структуры. Если бы ты не напоролся на ошибку - и дальше использовал бы ЕК и каскадные апдейты? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:33 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
kdvТо есть, выходит, ФБ плохой, MS SQL плохой MS SQL при попытке наложения такого каскадного FK ругается. И, согласись, вопрос не стоял "я тут со своей гениальной структурой БД, а он...". ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:37 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Уберите одно из вот этих FK: alter table COST add constraint FK_COST_DELIVERY foreign key ( SUPPLIER, DELIVERY_NO ) references DELIVERY ( SUPPLIER, DELIVERY_NO ) on update cascade; -xor- alter table COST add constraint FK_COST_PRODUCT foreign key ( SUPPLIER, PRODUCT ) references PRODUCT ( SUPPLIER, PRODUCT ) on update cascade; - и реализуйте обновление тех полей таблицы COST, что теперь без контроля со стороны FK, через after-update триггер его "бывшей" родительской таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:38 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Да кто его разберёт...Уберите одно из вот этих FK: alter table COST add constraint FK_COST_DELIVERY foreign key ( SUPPLIER, DELIVERY_NO ) references DELIVERY ( SUPPLIER, DELIVERY_NO ) on update cascade; -xor- alter table COST add constraint FK_COST_PRODUCT foreign key ( SUPPLIER, PRODUCT ) references PRODUCT ( SUPPLIER, PRODUCT ) on update cascade; - и реализуйте обновление тех полей таблицы COST, что теперь без контроля со стороны FK, через after-update триггер его "бывшей" родительской таблицы. Ну, и ссылочную целостность по удаленному FK поддерживать тоже через триггер. В принципе, да, но легче переделать схему на суррогатные ключи - тогда каскадное обновление вообще не потребуется. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 14:42 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
PolesovПривет. Вопрос по каскадным обновлениям внешнего ключа. Структура БД: Таблица поставщиков: ... Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... С уважением, Poleosv. Ой, спасибо, положил ссылку в закладки. У меня начальник изредка пытается начать руководить разработкой детальной структуры БД, ему тоже естественные ключи по необъяснимый причине нравятся, вот и этот пример будет в копилке. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2018, 15:19 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Убийственные денормализация и избыточность! ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 09:36 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
интересный топег. про КГ/АМ уже было? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 11:48 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Мимопроходящий, было, но в более мягкой форме. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 11:55 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Мимопроходящийинтересный топег. про КГ/АМ уже было?Весь топик про это, после первого поста общественность другой версии не выдвигала. С небольшими лирическими отступлениями типа "начальник-тиран". ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 12:26 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
12.02.2018 12:26, Ivan_Pisarevsky пишет: > Весь топик про это, после первого поста общественность другой версии не выдвигала. > С небольшими лирическими отступлениями типа "начальник-тиран". спасибо. я так и думал. зы: весь топег не Асилил, ибо в моменты алкогольного воздержания становлюсь чрезвычайно нетолерантным. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2018, 12:34 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Polesov, Может быть я не прав, но у вас в таблице поставщиков только 1 поле: Код: sql 1. 2. 3.
судя по всему в этом и проблема. Вы пытаетесь использовать "ИМЯ" поставщика. Но если в эту таблицу добавить "код поставщика" (условный для вашей БД, можно даже инкремент) и при добавлении записей в другие таблицы использовать не имя, а код - то при изменении имени никто не пострадает. И целостность данных будет, и имя можно исправить. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2018, 10:01 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
akrush, дык весь топик ему об этом твердят ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2018, 10:03 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Симонов Денис, Извините, может не заметил, но Полесову все говорят что это проблема связей и т.п. А вот добавить отдельное поле "код поставщика" я не увидел, поэтому и написал сообщение. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2018, 10:16 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
akrush, нет, ему говорят что естественные ключи зло, и каскадные обновления то же зло. Что собственно мало отличается от того, что ты озвучил ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2018, 10:21 |
|
foreign key on update cascade
|
|||
---|---|---|---|
#18+
Симонов Денис, некоторым людям нравится магия каскадного обновления. Некоторые люди полагают, что использование естественных ключей позволит "работать проще": обойтись совсем простыми SELECT (без соединений), ускорить получение данных ("джойны тормозят"). В действительности, дело прежде всего в плохом знании SQL а также особенностей используемой СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2018, 11:30 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1561239]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
2ms |
others: | 307ms |
total: | 461ms |
0 / 0 |