Как построить индекс Oracle Text на организованной таблице индексов?

"Как я могу использовать Oracle Text и Index Organized Table"

Вы не можете. Таблица, организованная по индексу, в основном представляет собой просто индекс (есть объект таблицы, но он является заглушкой). Мы не можем строить индексы на индексах, это просто ограничение архитектуры базы данных.

Но почему вы хотите это сделать? Нет смысла создавать эту таблицу с помощью organization index. Варианты использования IOT ограничены; в основном они полезны для таких вещей, как поиск справочных данных, которые обычно имеют структуру со значением ключа: мы всегда ищем описание по ключу, другого пути доступа нет, и мы обычно используем оба столбца в нашем SQL.

Любой индекс с CLOB не подходит для этого класса вариантов использования. Тот факт, что вы хотите искать текст самостоятельно, подтверждает это. Вам нужно построить обычную таблицу кучи для вашего CLOB. Затем вы можете создать текстовый индекс.

Я предполагаю, что вы хотите объединить полнотекстовый поиск с другими фильтрами. Если это так, вам следует проверить тип индекса CTXCAT. Это другой тип текстового индекса, который позволяет нам создавать составной индекс из обычных столбцов и столбцов с возможностью поиска по произвольному тексту. Таким образом, вы можете запустить запрос, чтобы найти значения TEXTS, содержащие слово «велосипед», где числовое значение больше некоторого значения, подобного этому:

select from hr.txt_test 
where CATSEARCH(texts, 'bicycle', 'some_numeric_param > 23')> 0; 

Еще одним преимуществом индексов CTXCAT является то, что они являются транзакционными, поэтому нам не нужно поддерживать их с помощью фоновых заданий. Главный недостаток заключается в том, что они не очень подходят для больших фрагментов текста. Так что, возможно, они не подходят для вашей ситуации. Подробнее.

"Мне нужна большая таблица, упорядоченная по SOME_NUMERIC_PARAM с текстовым полем"

Я предполагаю, что вы исключили разделы (из-за лицензирования?). Поскольку вы находитесь на 12c, есть вероятность, что кластеризация атрибутов может вам помочь. Это «директива уровня таблицы, которая группирует данные в непосредственной физической близости на основе содержимого определенных столбцов» (из документации). Однако кластеризация атрибутов работает только при заполнении таблицы с помощью операций вставки прямого пути, перемещения данных или создания таблицы: обычные операторы DML не применяют ее.

"Опять в стиле ebay, когда люди начинают с чего-то очень распространенного, например samsung, и имеют несколько вариантов сортировки"

Таким образом, особенность таких сайтов, как eBay, Google и многих других тотемов масштабируемости, заключается в том, что они вкладывают много усилий в кэширование, индексирование и специализированные структуры данных. Во многом они похожи на хранилища данных с сильно денормализованными структурами данных. Таким образом, многие поисковые запросы eBay фильтруют результаты не по полнотекстовым поискам описаний предметов, а путем фильтрации и сопоставления структур, подобных измерениям: изначально даже не таблиц базы данных, а кэшей в памяти.

Общие шаблоны поиска кэшируются и представлены в виде раскрывающихся предложений. Они даже обрабатывают опечатки таким образом. Введите smasu в поле поиска eBay, и вы получите те же предлагаемые поисковые запросы, как если бы вы набрали samsu, т. е. список желаемых в настоящее время телефонов Samsung (а не ноутбуков или холодильников). Это на заказ. Вы не сможете этого сделать с Oracle Text из коробки.

Итак, все возвращается к тому, насколько вы действительно хотите быть похожими на eBay? Достаточно просто использовать такие сайты в качестве краткого описания функций, но реализовать эквивалентную функциональность — задача другого масштаба.