Hello, Aleksey! Boulitchev Aleksey wrote:
>>Или ткните носом где можно почитать почему alter table add constrain >>лучше? > > ИМХО предрассудки я уже объяснил. это не предрассудки. > а вот прямое указание типов вместо использования доменов - зло никакого зла. наоборот, создание доменов на каждый чих - зло. домен - это фактически тип. и если все идентификаторы именовать как create domain id integer not null а потом втыкать в клиентов, заказы и т.п., то код клиента <> коду заказа, это РАЗНЫЕ ТИПЫ, пусть они оба integer. > create domain PK bigint not null; а за bigint здесь вообще линейкой по пальцам. > по поводу порядка создания - считаю циклические зависимости ошибкой > проектирования, при написании скрипта вручную проблемам вроде как тоже > взяться неоткуда. блин. ну откуда извлекатель скрипта знает, в каком порядке правильно создавать create table +fk ? нужно проверять зависимости, можно натолкнуться на множественные, циклические и т.п. Гораздо проще вывалить create table + pk в АЛФАВИТНОМ ПОРЯДКЕ ТАБЛИЦ, а потом сделать alter table add fk. Даже если скрипт создается руками, один раз и на все времена, все равно imho глупо ориентироваться на порядок завязки таблиц по fk. > рассасываются проблемы с AUTOCOMMIT DDL and "Object in use" да без разницы. абстрактно, вообще, получить object in use на alter table add fk шансов меньше, чем create table +fk. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34 --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
