Где Cascade Update в ORACLE 10g

← →
Alex' (2006-08-14 17:23) [0]

При переводе базы из IB в ORACLE встала проблема обновления первичного индекса в ORACLE. "Parent Key Not Found".
Таблица родитель:
CREATE TABLE "PUBASKUE"."DEVICES"
( "DCID" NUMBER(3,0) NOT NULL ENABLE,
"OBJID" NUMBER(3,0) NOT NULL ENABLE,
"DEVID" NUMBER(3,0) NOT NULL ENABLE,
"DEVICE" NUMBER(3,0) NOT NULL ENABLE,
"SERNUM" VARCHAR2(30),
"NETADRR" VARCHAR2(7) DEFAULT "000.000" NOT NULL
)
CONSTRAINT "PK_DEVICES" PRIMARY KEY ("DCID", "OBJID", "DEVID")

Подчиненная:
CREATE TABLE "PUBASKUE"."JOINS"
( "DCID" NUMBER(3,0) NOT NULL ENABLE,
"OBJID" NUMBER(3,0) NOT NULL ENABLE,
"DEVID" NUMBER(3,0) NOT NULL ENABLE,
"JOINID" NUMBER(3,0) NOT NULL ENABLE,
"KTT" NUMBER(3,0),
"KTN" NUMBER(3,0)
)
CONSTRAINT "PK_JOINS" PRIMARY KEY ("DCID", "OBJID", "JOINID", "DEVID"

CONSTRAINT "FK_JOINS" FOREIGN KEY ("DCID", "OBJID", "DEVID")
REFERENCES "PUBASKUE"."DEVICES" ("DCID", "OBJID", "DEVID") ENABLE
Проблема обновления таб. "JOINS" возникает при обновлении поля "DEVICES"."DEVID" уже существующих записей.
Делал тригер на update "DEVICES" таже проблема. Что не учел?

← →
Desdechado © (2006-08-14 17:28) [1]

и где здесь ON UPDATE CASCADE ?

← →
ANB © (2006-08-14 17:28) [2]

Оракл не поддерживает каскадное обновление ключевых полей.
Вывод - не хрен обновлять.
Если сильно приперло - то ручками, аккуратно.
Т.е.
1) завести в родителе запись - дубль с новым ID
2) проапдейтить поле в подчиненной
3) грохнуть старую запись в родительской таблице.
4) в триггере лучше этого не делать.

← →
ANB © (2006-08-14 17:29) [3]

> ON UPDATE CASCADE ?

А такое уже есть в 10 ? Млин, я отстал от жизни. В 8-9 не было :(

← →
Desdechado © (2006-08-14 17:36) [4]

> Млин, я отстал от жизни.
Нет, по прежнему нет :(
Это я, пользуя такое в IB, не пользую такое в Оракле. Не было надобности. А, оказывается, и нет возможности. Только что проверил по докам.
Ну, не очень-то и хотелось.

← →
Alex' (2006-08-14 17:37) [5]

> Оракл не поддерживает каскадное обновление ключевых полей.
> Вывод - не хрен обновлять.Если сильно приперло - то ручками,
> аккуратно.Т.е.1) завести в родителе запись - дубль с новым
> ID2) проапдейтить поле в подчиненной3) грохнуть старую запись
> в родительской таблице.4) в триггере лучше этого не делать.
>

Да... тогда проблема, дело в том что это только начало, дальше еще каскадом 3 таблицы висит. С большим количеством данных и везде пользую DEVID.

> А такое уже есть в 10 ? Млин, я отстал от жизни. В 8-9 не
> было :(

В том то и дело что я не нашел. Это мысли на фоне MSSQL и IB.

← →
ANB © (2006-08-14 17:39) [6]

> Да... тогда проблема,

А зачем их обновлять ? Или ключи не сиквенсом сгенерены ? И каким боком каскад еще трех таблиц ? Они же должны были уже на другие ID завязаны, которые не меняются.

← →
ANB © (2006-08-14 17:43) [7]

> CONSTRAINT "PK_DEVICES" PRIMARY KEY ("DCID", "OBJID", "DEVID")

> CONSTRAINT "PK_JOINS" PRIMARY KEY ("DCID", "OBJID", "JOINID",
> "DEVID"

> CONSTRAINT "FK_JOINS" FOREIGN KEY ("DCID", "OBJID", "DEVID")

Вот за такие вещи надо бить ногами. Долго и нудно, пока не будет выбита вся дурь.
Сколько уже писано - не используйте естественные ключи, не делайте первичные ключи составными - грабли неизбежны, пусть не сразу, так потом вылезут. Не так уж трудно добавить в табличку поле ID и прикрутить к нему сиквенс. Если уж очень лениво - повесить триггер.
А все ограничения по уникальности на основе бизнес-логики надо вешать на уникальные индексы/ограничения (кому что больше нравится).

← →
Alex' (2006-08-14 17:44) [8]

DevID это "сетевой адрес устройства" который может меняться. Он входит в первичный ключ. Можно это обойти, но тогда придется перелопатить половину софта. А хотелось бы обойтись малой кровью.

← →
evvcom © (2006-08-14 17:45) [9]

Если проблемы с переносом, то разово можно грохнуть ключи, обновить данные и восстановить ключи. А если на постоянку такое, то неверное проектирование, однозначно.

← →
Alex' (2006-08-14 17:46) [10]

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

Я всегда за! И не только ногами! Дело в том что как всегда приходится переделывать чужeую работу.

← →
ANB © (2006-08-14 17:48) [11]

> Alex" (14.08.06 17:44) [8]

Тупорылый вариант :

declare v_Sql varchar2 (32000); begin -- Отключим все FK for R in (select C.Constraint_Name, C.Table_Name from User_Constraints C where C.Constraint_Type = "R") loop v_Sql := "alter table " || R.Table_Name || " disable constraint " || R.Constraint_Name; execute immediate v_Sql; end loop; -- Сюда вставить переколбаску БД commit; -- Включим все FK for R in (select C.Constraint_Name, C.Table_Name from User_Constraints C where C.Constraint_Type = "R") loop v_Sql := "alter table " || R.Table_Name || " enable constraint " || R.Constraint_Name; execute immediate v_Sql; end loop; dbms_utility.Compile_Schema (user, false); end;

> то разово можно грохнуть ключи

Грохать не кузяво. В оракле их можно просто отключить.

> Я всегда за! И не только ногами! Дело в том что как всегда
> приходится переделывать чужeую работу.

Найди прога, который так написал и побей его.

← →
Alex' (2006-08-14 17:55) [14]

> Найди прога, который так написал и побей его.

Неуспел :(, он уже уволился. А жаль...

Будем думать, спасибо люди!

можно сделать так:
1. constraint`ы объявить deferrable initially dererred
2. в after триггере for each row сохранить ID в переменой какого-нить пакета
3. в after "обычном" триггере проапдейтить все зависимое
4. пока это все наеб
нулось выполнить [13]

> [12] ANB © (14.08.06 17:49)

Можно. UK и FK легко, а вот с PK у меня были проблемы. Вероятно, есть какие-то ограничения, не разбирался. Я подобные вещи делаю так: у меня есть копия рабочей базы, в PL/SQL Developer есть инструмент сравнения структур, после этого можно смело грохать любые ключи, делать изменения и теперь можно восстановить все грохнутое.

Где Cascade Update в ORACLE 10g Найти похожие ветки