K>Сиквенс там в принципе нельзя использовать, т.к. значения генеряться не попорядку, а хаотично:
за счет этого "хаоса" и маштабируемость, а вот чтоб по порядку вы выстраиваете все транзакции в очередь.
K>
K>select NVL((select lit.itemid
K> from LookupItemTranslation lit
K> where lit.tableid = pTableID
K> ), 0)
K> into lcurrItemID
K> from dual;
K> if lcurrItemID = 0
K> then lItemID := 1;
K> else lItemID := lcurrItemID+1;
K> end if;
K>
просто добавте
select lit.itemid from LookupItemTranslation lit where lit.tableid = pTableID for update wait 5;
в начало и все транзакции выстроятся в очередь.
Здравствуйте, wildwind, Вы писали:
W>Так в чем же проблема наконец?
W>A и B это суррогатные ключи или нет? Если B зависит от A, то причем тут sequence?
Суть проблемы заключается вот в чём: вставка в эту таблицу происходит постоянно, причём не в определённой последовательности, а хаотично. Из-за этого существует высокая вероятность возникновения такого события — сессия S1 читает данные о колонке В из таблицы lit, т.е. temp := current(lit.B for in(A)), далее выполняется анализ переменной temp --> new(temp), в это время другая сессия S2 также получает temp := current(lit.B for in(A)) и new(temp) (т.е. S1.temp = S2.temp, а соответственно и new(S1.temp) = (newS2.temp)). После чего одна из сессий делает вставку --> данные хранящиеся в другой сессии уже устаревшие и при попытке вставки, генерится исключение
Так и не ясно, B суррогатный ключ или нет, но похоже что суррогатный.
Смысл выражений temp := current(lit.B for in(A)) и temp --> new(temp) для меня весьма туманен, но из того что я понял, могу сделать вывод, что генерация значений для B из последовательности решит вашу проблему. B будет уникальным ключом, а (A, B) — тем более. К тому же B в таком случае можно сделать PK.
Здравствуйте, wildwind, Вы писали:
W>Так и не ясно, B суррогатный ключ или нет, но похоже что суррогатный.
CREATE TABLE SUN.LOOKUPITEMTRANSLATION
(
TABLEID NUMBER(4) NOT NULL,
ITEMID NUMBER(3) NOT NULL,
TEXT VARCHAR2(30 BYTE) NOT NULL
)
CREATE UNIQUE INDEX SUN.UQ_TABLEITEM ON SUN.LOOKUPITEMTRANSLATION
(TABLEID, ITEMID)
LOGGING
TABLESPACE ...
ALTER TABLE SUN.LOOKUPITEMTRANSLATION ADD (
CONSTRAINT UQ_TABLEITEM UNIQUE (TABLEID, ITEMID)
USING INDEX
TABLESPACE ...
ALTER TABLE SUN.LOOKUPITEMTRANSLATION ADD (
CONSTRAINT FK_TABLEID FOREIGN KEY (TABLEID)
REFERENCES SUN.LOOKUPITEM (TABLEID)
ON DELETE CASCADE)
/
W>Смысл выражений temp := current(lit.B for in(A)) и temp --> new(temp) для меня весьма туманен, но из того что я понял, могу сделать вывод, что генерация значений для B из последовательности решит вашу проблему. B будет уникальным ключом, а (A, B) — тем более. К тому же B в таком случае можно сделать PK.
Сам по себе ключ В не уникален, он уникален в комплексе с ключём А. Если использовать последовательность, то её значение с какой-то переодичностью придёться сбрасывать, ведь нумерация идёт не по порядку. И как потом последовательность будет возвращать, например число 5, если последнее значение, которое она сохранила, было 12?
Здравствуйте, kallisto, Вы писали:
K>Здравствуйте, wildwind, Вы писали:
W>>Так и не ясно, B суррогатный ключ или нет, но похоже что суррогатный. K>
K>CREATE TABLE SUN.LOOKUPITEMTRANSLATION
K>...
Может быть вы не знаете, что значит суррогатный ключ?
K>Сам по себе ключ В не уникален, он уникален в комплексе с ключём А. Если использовать последовательность, то её значение с какой-то переодичностью придёться сбрасывать, ведь нумерация идёт не по порядку.
Давайте попробуем по-другому. Используя последовательность, вы получите такие значения
Здравствуйте, wildwind, Вы писали:
W>Если ключи суррогатные, нарушаться нечему. Сделав B уникальным, получите из него простой PK, это лучше чем составной.
Изначально предполагалось, что В в пределах одного значения А, будет нумероваться заново, например
[sql]
Зверь
--------------
ID_An| Title
--------------
1 | Заяц
2 | Лиса
Здравствуйте, kallisto, Вы писали:
K>Здравствуйте, wildwind, Вы писали:
W>>Если ключи суррогатные, нарушаться нечему. Сделав B уникальным, получите из него простой PK, это лучше чем составной.
K>Изначально предполагалось, что В в пределах одного значения А, будет нумероваться заново, например
Здравствуйте, wildwind, Вы писали:
W>Зачем? Клиент/начальство захотели красивые номера?
Да, но красивую нумерацию им можно обеспечить в самом приложении, не привязываясь к колонке В, т.е. считывать все данные дла опр-го А, а потом, перебирая их, делать "красивую" нумерацию... Наверно, так и сделаю. Спасибо
