Репликант
Ну то, что не для красоты это мы знаем :) Да, нормализация - не самоцель, но забивать или переигрывать с этим понятием не следует. Вот вы kondi порекомендовали дополнительный джойн, а надо ли оно ему? Вдруг у него экспериментальная рецептура состав меняет, а ее наименование не изменяется, т.е у них на предприятии бизнес-правила допускают существование нескольких объектов с одинаковыми наименованиями, но при этом с разными артикулами/кодами/ИД, например, несколько штук "торт шоколадный №28", но разными составами. Т.е опять должен определять предметник, т.е kondi. С технической точки конечно все равно, но вот с человеческой - поиск чего-либо по наименованию, а не по числовому ИД гораздо удобнее потому что люди имена запоминают лучше чем числа

Именно для поиска по контексту эта архитектура и расчитана. При таком поиске, еще раз заявляю, будут найдены все объекты с похожим или одинаковым наименованием. При ~500000 наименований все работает шустро.

Ну, я их особо и не использовал, просто обявлял символьный тип, а потом приводил в нужный.

Вопрос был конкретный: есть такое в Oracle или там также как в MSSQL на основе системных типов данных или sql_variant? (не идти же мне в раздел по Oracle) ^)

Да, можно создать и использовать подобие объектов (я с ними не работаю). Эта возможность появилась в последних версиях Oracle

kondi
2 Jinn
Подскажите пожалуйста новую структуру, на первый (мой поверхностный взгляд) без пустышек рецептур для сырья не обойтись?

Пояснения:
Что такое рецептура? Это название и некие параметры расчета этой рецептуры.
Что такое содержание рецептуры? Это - что и сколько входит в рецептуру.
Очень важно не путать «рецептуру» и «содержание рецептуры»

Я не стал приводить пример (желающие сами посмотрят), но пример несколько некорректен. Изделие №1 изготовленное по рецептуре №1 не может входить в полуфабрикат №1 который, в свою очередь, входит в изделие №1. Если это отходы - то они должны учитываться отдельно в разделе сырье (которое не имеет рецептуры).

Но выглядеть это будет примерно так:
{01,12}Изделия
{02,13} Изделие №1
{03,14} Рецептура №1
{04,15} Рецептура №2
{05,16}Полуфабрикаты
{06,17} Полуфабрикат №1
{07,18} Рецептура №3
{08,19} Рецептура №4
{09,20}Сырье
{10,21} Сырье №1
{11,22} Сырье №2

Здесь приведено дерево уже с именами. В скобках указаны ID дерева и наименования.

Таблица параметров будет выглядеть так (ID параметра, ID владельца, ID наименования, Значение).

23,03,18,(50 кг)
24,03,21,(50 кг)
25,04,18,(40 кг)
26,04,21,(80 кг)
27,07,14,(20 кг)
28,07,22,(10 кг)
29,08,21,(30 кг)
30,08,22,(10 кг)

Как видно, в качестве владельца параметра указывается положение в дереве, а в качестве наименования параметра положение в таблице наименований, вне зависимости от положения этого наименования в дереве.
Разложение в вертикальную таблицу как раз и позволяет изюежать пустых полей. Ну а алгоритм использования параметров у каждого свой.
Логика такого хранения, может быть, и не совсем понятна на первый взгляд, но после "привыкания" снимаются многие проблемы и проблемки с использованием справочных данных.

2 Репликант

Никаких join'ов не надо, поиск осуществляется одним запросом, примерно таким:

select /*+Rule*/
tree_id, owner_id, name_id,
(select /*+Rule*/ N.Names
from Dict_Name N
where N.Name_ID=T.Name_ID) as Names,
LEVEL
from Dict_Tree T
start with Name_ID in (select /*+Rule*/ N.Name_ID
from Dict_Name N
where N.Names like '%VAL%')
connect by prior owner_id=tree_id

Этот запрос выведет всю иерархию до искомого слова включительно, в обратном порядке.