одновременное изменение первичного и внешнего ключей

← →
zorik © (2007-12-03 10:21) [0]

Есть две таблици, связаные по primary - foreign key. Как составить запрос, чтоб изменить значение primary key в первой таблице и значение foreign key во второй. И возможно ли такое без отключения constraints. В литературе наткнулся на cascade, но то ли это? К тому же синтаксиса не нашел

← →
Sergey13 © (2007-12-03 10:29) [1]

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

← →
zorik © (2007-12-03 10:38) [2]

В констрейнте каскаде не прописано, база не моя, немножко кривая. Смысл обновления в переходе с автоинкрементних ключей на псевдоавтоинкрементные (типа спецкод*1000 + значение генератора). Работа разовая, конечно. Пока вижу 2 выхода:
1. Убить констреинт и изменить значения в двух таблицах. Потом заново создать его
2. Пересоздать констреинт с параметром каскаде. И изменить значения

← →
Sergey13 © (2007-12-03 10:44) [3]

> [2] zorik © (03.12.07 10:38)
> В констрейнте каскаде не прописано

Ну так пропиши и попробуй. Пробовать это желательно на копии БД.

> типа спецкод*1000 + значение генератора

Не маловато будет 1000 значений? Почему просто не сделать составной ПК из двух полей?

← →
sniknik © (2007-12-03 10:55) [4]

> Смысл обновления в переходе с автоинкрементних ключей на псевдоавтоинкрементные (типа спецкод*1000 + значение генератора).
зря. имхо. один искуственный ключ менять на другой такой же, еще более искуственный...
или смысл в том что в ключ закладывается какаято инфа (типа спецкод), и он становится естественным? тем более зря, проще не шифровать эту инфу в коде, а писать ее в отдельное поле (и уж если нужен ключь именно по этой инфе то сделать его составным, вместе с автоинкрементом... хотя и это лишнее, автоинкремент самодостаточен в плане уникальности значений).

← →
zorik © (2007-12-03 10:55) [5]

> Не маловато будет 1000 значений? Почему просто не сделать

это для примера 1000.

> составной ПК из двух полей?

что-то такое и будет.

всем спасибо

← →
sniknik © (2007-12-03 10:57) [6]

+
в общем, не вижу смысла в "Смысле обновления ...", в любом варианте получается только хуже.

← →
zorik © (2007-12-03 11:06) [7]

2
> sniknik © (03.12.07 10:57) [6]

нужно разделить базу по предприятиям. Их 5 штук. Сейчас все вместе. И предвидеть и реализовать возможность слития в одну базу. "Слитие" будет проходить примерно раз в месяц. Так вот, если использовать такой механизм, то сливать все в кучу можно будет с меньшими траблами -- не будет одинаковых ключей

← →
Desdechado © (2007-12-03 11:27) [8]

Так добавь поле "код предприятия" и включи его в составной первичный ключ.
Всякие формульные ключи слишком геморройны в поддержании, особенно если нужно учесть справочник предприятий в виде таблицы с возможностью внешних ключей на нее.
А то у тебя сейчас получается ничуть не лучше

> база не моя, немножко кривая

← →
zorik © (2007-12-03 12:02) [9]

> Так добавь поле "код предприятия" и включи его в составной
> первичный ключ.

протестировал что-то вроде:
CREATE TABLE TESTMAIN ( ID INTEGER NOT NULL, NAME VARCHAR(10) ); ALTER TABLE TESTMAIN ADD CONSTRAINT PK_MAIN PRIMARY KEY (ID); CREATE TABLE TESTCHILD ( ID INTEGER NOT NULL, ID_MAIN INTEGER NOT NULL, NAME VARCHAR(10) ); ALTER TABLE TESTCHILD ADD CONSTRAINT PK_CHILD PRIMARY KEY (ID, ID_MAIN); ALTER TABLE TESTCHILD ADD CONSTRAINT FK_CHILD_MAIN FOREIGN KEY (ID_MAIN) REFERENCES TESTMAIN (ID);

Вроде работает :)

← →
sniknik © (2007-12-03 12:31) [10]

> Так добавь поле "код предприятия" и включи его в составной первичный ключ.
имхо, и этого не надо...
автоинкремент в качестве исскуственного ключа самое то, за редкими исключениями...
в базе для связок нужен именно он, неужели при объединении баз из разных предприятий сложно добавлять так чтобы он перерассчитывался?

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

хотя ладно, имхо все, а то счас очередной холивар естественный vs искуственный ключ начнется.

← →
Desdechado © (2007-12-03 12:46) [11]

sniknik © (03.12.07 12:31) [10]
Имхо, ты запутался. Слишком много "если".

← →
Johnmen © (2007-12-03 12:51) [12]

> zorik © (03.12.07 12:02) [9]

Это про что-то другое ты наваял.

> sniknik © (03.12.07 12:31) [10]
иногда подход автора имеет смысл, может, на этом ключе сто таблиц висит, и совершенно неохота допполе тянуть по всем ним

упс, вариант zorik © (03.12.07 12:02) [9] не пройдет. нельзя сослатся на таблицу testchild.
Представте несколько баз типа:
Предприятие(ключ) -> Месторождение(ключ_предприятия, ключ) -> Скважина(ключ_месторождения, ключ) -> Замеры(ключ_скважини, ключ)
Они заполняются на разных предприятиях независимо. Потом надо все это сливать в одно. Разными будут только ключи предприятия, остальные могут совпадать. При слитии надо будет использовать генераторы "главной" базы для получения значений ключей. Такой вариант тоже имеет право на жизнь. Но не знаю как легче реализовать. В любом случее будет гемор

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

> [14] zorik © (03.12.07 12:55)

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

Набрался кучу полезностей, вариантов, мнений, технологий. Пошел переваривать :)))

одновременное изменение первичного и внешнего ключей Найти похожие ветки