Автоинкрементные поля - вставка пропущенный значений

← →
Ega23 © (2011-10-04 17:33) [40]

> В случае какого-то сбоя в автоинкременте

8 лет за MSSQL. От 7.2 до 2005, вместе с портативными версиями. Ни одного сбой не видел.

> Также можно одну секвенцию применить к нескольким таблицам,
> что тоже иногда полезно....

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

← →
pavel_guzhanov © (2011-10-04 17:49) [41]

> Хотя сейчас уже наверняка можно

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

> 8 лет за MSSQL. От 7.2 до 2005, вместе с портативными версиями.
> Ни одного сбой не видел.

Я 8 лет за FireBird и Interbase. 4 года за DB2. Сбои в автоинкременте бывали... конечно редко, но все-таки бывали.

← →
Anatoly Podgoretsky © (2011-10-04 20:47) [42]

> pavel_guzhanov (04.10.2011 17:49:41) [41]

В Interbase/FireBird нет автоинкримента

← →
pavel_guzhanov © (2011-10-04 22:13) [43]

> В Interbase/FireBird нет автоинкримента

Я же говорю про секвенции и генераторы. В Interbase/Firebird мы используем генераторы.

← →
Anatoly Podgoretsky © (2011-10-04 22:27) [44]

> Я же говорю про секвенции и генераторы. В Interbase/Firebird
> мы используем генераторы.

Вообще то говорил
> Сбои в автоинкременте бывали

← →
pavel_guzhanov © (2011-10-05 09:22) [45]

> Вообще то говорил
> > Сбои в автоинкременте бывали

Признаю, неправильно сформулировал :о)

> pavel_guzhanov © (04.10.11 16:47) [39]
> В случае какого-то сбоя в автоинкременте гораздо проще найти
> генератор или секвенцию по разумному наименованию, а не
> по сгенеренному СУБД.

В случае какого-то сбоя проще вообще ничего не искать, кроме имени таблицы:

DBCC CHECKIDENT ("table_name")

> Также можно одну секвенцию применить к нескольким таблицам,
> что тоже иногда полезно....

Не вижу ни одного полезного применения.

Если сущности разделяют общее пространство идентификаторов, то они должны быть связаны какой-то общностью.
В терминах ООП такой общностью является отношение наследования, т.е. классы-сущности имеют общего предка.
При отображении такой структуры на реляционную модель получается мастер-таблица (класс-предок) и дополнительные таблицы (классы-потомки), связанные с мастером отношением один-к-одному:
CREATE TABLE AbstractEntity( ID bigint not null identity(1,1) primary key, -- common entity attributes ); CREATE TABLE ConcreteEntity1( ID bigint not null primary key, -- private entity attributes CONSTRAINT FK_ANCESTORKEY1 FOREIGN KEY(ID) REFERENCING AbstractEntity(ID) ON DELETE CASCADE ON UPDATE CASCADE ); CREATE TABLE ConcreteEntity2( ID bigint not null primary key, -- private entity attributes CONSTRAINT FK_ANCESTORKEY2 FOREIGN KEY(ID) REFERENCING AbstractEntity(ID) ON DELETE CASCADE ON UPDATE CASCADE );
Если сущности не имеют общих атрибутов, то вообще нет смысла в общем пространстве идентификаторов.

> Если сущности не имеют общих атрибутов, то вообще нет смысла
> в общем пространстве идентификаторов.

Проблемы начинаются, когда имеют. Postgres в этом плане с его наследованием таблиц просто шикарен.

Автоинкрементные поля - вставка пропущенный значений Найти похожие ветки