Доброго дня всем!
В набор скриптов создания демо схемы OE для Oracle 18c (взят с GitHub) входит скрипт coe_v3.sql.
В нем есть строки:
---
CREATE TABLE inventories
( product_id NUMBER(6)
, warehouse_id NUMBER(3) CONSTRAINT inventory_warehouse_id_nn NOT NULL
...
, CONSTRAINT inventory_pk
PRIMARY KEY (product_id, warehouse_id) DISABLE NOVALIDATE);

CREATE INDEX inventory_ix
ON inventories (warehouse_id, product_id);

ALTER TABLE inventories ENABLE CONSTRAINT inventory_pk;
---
Эти операторы идут подряд, т.е. загрузки данных в таблицу между ее созданием и созданием индекса нет.

Вопрос: зачем PRIMARY KEY создается с опциями DISABLE NOVALIDATE, потом создается НЕуникальный индекс с теми же полями, но в ОБРАТНОМ ПОРЯДКЕ, и потом PRIMARY KEY активируется?
В SQL Developer видно, что в свойствах таблицы OE.inventories присутствует PRIMARY KEY inventory_pk, у которого индекс inventory_ix.

В самом скрипте есть такой комментарий:
-- Enhancement request 2376117 suggested to have a PRIMARY KEY constraint
-- supported by a non-unique index
-- Starting with 10i R1, this is implemented in table INVENTORIES:

Не понимаю, в чем смысл такого тройного трюка с PK и индексом:
1. их создание разделено;
2. индекс НЕуникальный (т.к. одно из полей product_id не объявлено как NOT NULL);
3. у PK порядок полей один, а у индекса - противоположный
И как обеспечивается уникальность PRIMARY KEY, если он опирается на НЕуникальный индекс?

Вячеслав , правильно ли я понял, что в данном случае весь смысл _разделения_ создания первичного ключа и индекса состоит в том, чтобы использовать для PK _неуникальный_ индекс (вообще-то созданный для _другой_ цели - т.к. в нем даже порядок поле другой) и тем самым не плодить для PK отдельный _уникальный_ индекс по тем же полям (но в другом порядке)?
То есть просто экономия на пространстве под второй индекс (все же равно PK будет уникальным даже на базе неуникального индекса).
Ведь в данном случае отложенного ограничения фактически нет - PK активируется сразу после создания индекса, когда таблица еще пустая.

Вячеслав , я оставил как было в оригинальном скрипте. Просто пытался понять, в чем _может быть_ смысл неочевидного действия, которое выполнили заведомо профессиональные люди. И чтобы научиться чему-то новому.
В любом случае спасибо за ответ.

Stax , согласен, я некорректно написал. Да, индекс создали неуникальным и с именем, _отличным_ от имени PK. Но Oracle подхватил именно этот индекс для PK, не создавая нового (с полями в том порядке, в котором они описаны в самом PK).

В более ранней версии скрипта (файл oe_cre.sql в том же архиве демо, не является актуальным и не вызывается при создании схемы OE в Oracle 18c) была всего одна строчка вместо трех:
Не было никакого отдельного создания индекса, да еще с полями в обратном порядке по сравнению с PK.
_Уникальный_ индекс создавался автоматически при определении PK (при создании таблицы).
Получается, сейчас создание индекса отделено от активизации PK только для того, чтобы для PK использовать _НЕуникальный_ индекс. У меня других идей нет.
Если у Вас есть идеи, для чего еще это могло быть сделано - поделитесь.

Еще одна любопытная ситуация в скрипте coe_v3.sql (из того же комплекта создания демо схемы OE), где есть такие строки, идущие подряд:
---
---
В данном случае создается _уникальный_ комбинированный индекс и только потом отдельно создается _одноименный_ PK с теми же полями (который, конечно, использует этот индекс).
Но вопрос: зачем уникальный индекс создавать отдельно от PRIMARY KEY и до него?
Ведь если CONSTRAINT PK просто описать в CREATE TABLE, то создание уникального индекса произойдет автоматически и последующие две строки будут просто лишними, верно?
Или в таком выделении создания уникального индекса и PK в отдельные команды есть какой-то неочевидный смысл?
Просто хочется понять - вдруг это фишка оптимизации или еще что-то полезное...

andrey_anonymous , спасибо за развернутый ответ. Это то, что нужно для понимания действий разработчиков демо.

По ходу дела возник еще один вопрос, связанный с демо схемой OE, но более общий.
Можно ли в Oracle каким-то простым способом вывести / сохранить дерево вызовов скриптов SQL (из SQL Plus или из какой-то другой программы)?

В схеме OE около 70 SQL-скриптов, но вся схема создается запуском единственного скрипта oe_main.sql, который запускает другие скрипты, которые запускают другие скрипты, которые запускают ...
Существует ли средство отладки Oracle или какой-то иной механизм, который позволяет посмотреть это дерево вызовов всех этих скриптов (например, после окончания работы стартового скрипта)?
Желательно без внесения изменений в каждый скрипт (типа добавления в начало скриптов вывода сообщения, что данный скрипт запущен).

Ясно. Раз готового средства в инструментах работы с Oracle SQL нет - придется пользоваться такими подручными средствами.