Hi dmitryx!

> Вот если бы расширить статью, чтобы можно было и на Oracle применить нечто
> похожее

На Oracle таких извращений ВООБЩЕ не требуется (т.к. там нету этого самого
IDENTITY). Там всё просто и прямолинейно - прямо ПЕРЕД вставкой записи НА
КЛИЕНТЕ ты можешь получить очередное значение SEQUENCE и тут-же его
прописать в поле PK, в поля FK и вообще всюду где тебе необходима ссылка на
новую запись.
Конечно для этого в таблице должен быть прописан адекватный триггер - такой,
который не станет БЕЗУСЛОВНО переписывать значение PK поля. Т.е. триггер
должен сначала проверить NEW.PK на содержание там чего-либо отличного от
NULL - и лишь если там NULL то проводить замену, извлекая очередное значение
последовательности.

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> А между получением "очередного SEQUENCE " и записью ее в качестве ссылки,
> таблицы будет заблокировна?

Sequence не имеет никакой связи с таблицами - это отдельная сущность. И
никаких блокировок не возникает (не считая конечно тех блокировок системных
таблиц, которые возникают ВО ВРЕМЯ извлечения очередного значения
последовательности - но это мизерное время, AFAIK уменьшаемое к тому-же
использованием опции CACHE).
Видимо ты не совсем меня понял - я имел в виду работу именно с клиентскими
курсорами - т.е. с фоксовым курсором - когда в него идёт вставка записи - а
не с серверной таблицей (там конечно тоже на всякий случай прописан код
заполнения ID - в BEFORE INSERT триггере). Т.е. мы уже на клиенте получаем
"полноценные" записи - с корректными ID/FK - которые потом уже тривиально
переносятся в серверные таблицы.

> А что мешает такой же метод реализовать и в SQL SERVER?

Ничего - за исключением того, что необходимо создать ХП эмулирующую Sequence
(aka фоксовый NewID) :)

> Он даже в учебном курсе MS по SQL Server описан!

Тут как говорится "я не Копенгаген" :)

> Для этого достаточно отказаться от IDENTITY

Именно так! Просто обычно когда высказываешь такие мысли, SQL-ники тут-же
набрасываются с кулаками - видимо этот инструмент является для них священной
коровой :)

> использовать DEFAULT со вставкой "невозможного" PK и написания триггера на
> INSERT, который этот самый "невозможный" PK заменит на "человеческий"

Ну наверное в качестве "невозможного" сойдёт и NULL ;) Так что никакого
особого Default и не требуется. Тут единственная сложность - позволит ли
сервер дойти до триггера, если попытаться таки вставить запись с NULL-ом в
качестве PK (например просто не указывая поля PK в списке INSERT). Oracle
это позволяет (конечно доходит именно до BEFORE триггера - если мы там не
укажем допустимого ID то далее дело не пойдёт).

2 dmitryx

Честно говоря, я полагал что если уж нам нужен ID на клиенте, то его надо
получать не в BeforeInsert (который исполняется уже при попытке сохранить
данные из курсора на сервер - обычно при вызове TableUpdate()), а именно
перед вставкой записи в фоксовый курсор. И тут уже нет принципиальной
разницы - используется CAD или RV или SPT запросы. Конечно в случае CAD
можно прописать в нём самом метод-обёртку для получения очередного значения,
и уже этот метод дёргать из основного кода - при этом упрощается миграция на
другие СУБД - например на тот-же MS SQL - где вместо SELECT SEQ_SOME.NextVal
FROM Dual будет вызываться наша ХП. Или вообще DownSizing на фоксовую
базу - где будет вызываться широко известный в узких кругах NewID :)

Что же касается случая когда нам на клиенте этот ID не нужен (хотя мне
кажется что он нужен практически всегда - уж если и не для вставки связанных
записей - в которых надо заполнять поля FK - то хотя-бы для того чтобы после
перезапроса вернуться на "ту самую" запись), то тут должен вступать в работу
сам сервер - он определяет что с клиента не было задано "подходящего" ID, и
сам его прописывает - в триггере конечно. Примерно таком:

CREATE OR REPLACE TRIGGER TBI_MyTable
BEFORE INSERT
ON MyTable
FOR EACH ROW
BEGIN
IF :NEW.ID IS NULL THEN
SELECT SEQ_MyTable.NEXTVAL INTO :NEW.ID FROM DUAL;
END IF;

EXCEPTION
WHEN OTHERS THEN
NULL;
END;

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> SQL Server даже не позволит сам Constraint создать Primary Key на поле с
> NULL.

Вопрос не в этом то :) Вопрос в том, чтобы можно было исполнять команды типа
INSERT INTO ... НЕ указывая при этом никакого значения для поля PK - вообще
не указывая его в списке заполняемых полей - и оно тогда по умолчанию
получается содержит null (в смысле в псевдо-записи видимой в триггере - :NEW
в Oracle - реально конечно в таблицу это никогда не запишется - т.к. триггер
заменит null на подходящее значение, а если не заменит, то ограничение не
пропустит такую запись). А на поле PK естественно установлено ограничение
NOT NULL.

> Так, что constraint DEFAULT надо создать при таком способе генерации PK.

Жаль что SQL Server тут несколько ограничен и требует дополнительных
телодвижений портящих всю красоту :(

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> Что-то я вас не понял, или ORACLE работатет не так, как MS SQL!

Видимо не так...

> В MS SQL у вас просто до триггера дело не дойдет, т.к. ограничитель
> Primary Key НЕ ПОЗВОЛЯЕТ вставлять NULL в такое поле, а Constraints ВСЕГДА
> срабатывают РАНЬШЕ,чем AFTER триггеры.

Я писал про BEFORE триггер - он замечательно срабатывает.

> По-мойму, красивое и логичное решение.

IMHO нет - лишнее телодвижение с DEFAULT -1 (или что там будет в качестве
"допустимого но невозможного") всё портит :( Хотя я и не сомневаюсь что оно
работоспособное - но в Oracle всё-же выходит "красивше" :)

Posted via ActualForum NNTP Server 1.3