mayton,

погугли (дополнительно к индекс-организованным таблицам) "oracle bitmap index structure"
что-нибудь вроде доки или здесь посмотри - www.juliandyke.com/Presentations/BitmapIndexInternals.pp

bitmap-индекс это попытка обеспечить быстрый доступ (в том числе по комбинации) для полей, у которых набор значений в домене мал, а число строк, хранящих эти значения - огромно, путем кодирования в битмап-полях идентификаторов строк, в которых появляется то или иное значение/комбинация.
В части скорости доступа к по настоящему большим наборам данных при строчном хранении - штука фантастическая, в обмен на жертвы в части совместной доступности таблиц для изменений и сжирание процессора до степени каления.
во всяких, близких по объемам к настоящим, хранилищах поверх oracle database без этого вантуза не живут

mayton,
про восстановление, похоже, ты меня неправильно понял - я не про логи, восстановление и целостность говорил совсем.
вот твоя колоночная таблица
coedbmsTable:
name[Varchar2(100)] = {Маша,Вася, Вася, Петя, Федя, Ира, Паша, Витя, Саша, Галя, Валя}
age[Number(3)] = {10 ,40 ,65 , 34 , 25 , 42 , 38 , 56 , 57 , 18 , 31 }

вот запрос:
select name,age from coedbmsTable where age between 10 and 30

вот результат, который вернул твой поиск:
name[Varchar2(100)] = {Маша, Федя, Галя}
age[Number(3)] = {10 , 25 , 18 }

а клиенту, ты хочешь (можешь хотеть) отдать
{{name, age}
{Маша, 10},
{Федя, 25},
{Галя, 18}
}

то есть преобразовать результат из колоночного преставления в вариант строчного.
то есть восстановить строки из колонок - в этом смысле.
и в этой логике нет никаких хранимых идентификаторов строк.
------------------------------
- по поводу остального
ты говоришь примерно следующее (я так тебя понимаю):
1) индекс позволяет а) осуществить поиск значения строки за логарифмическое время и б) автоматически поддерживают сортировку по возрастанию-убыванию значений. гут - хочу - пусть у меня хранение каждой колонки будет в виде индексного дерева.
т.е. если в базе два Васи и одна Маша, то получится что-то такое
{Вася:32CEA158B6D90409E0530820A8C012BB, Вася:32CEA158B6D90409E0530820A8C013BB,
Маша:32CEA158B6D90409E0530820A8C011BB}
или такое
{Вася:{32CEA158B6D90409E0530820A8C012BB,32CEA158B6D90409E0530820A8C013BB},
Маша:32CEA158B6D90409E0530820A8C011BB}
здесь Васю сжали для экономии места, но без задействования битмап-карт

2) тогда сама таблица выродится в набор идентификаторов строк (rid/rowid/"номеров_строк" - guid), к которым и будут привязаны
хранимые в индексе значения,а хранить его тоже в индексе, чтобы быстро добираться до идентификатора строки по его значению.

3) а чтобы восстановить строку по условию name='Maша' (Маша - уникальна) я полезу в столбец name
и по ключу 'Маша' отыщу хранимый в индексе идентификатор строки, найду в индексе
{'Маша:32CEA158B6D90409E0530820A8C011BB'},
далее, т.к. просили меня Select *, то используя уже '32CEA158B6D90409E0530820A8C011BB' я полезу в индексы, обратные к
виду {ключ=значение_поля, значение = идентификатор строки таблицы}
индексирующие сами идентификаторы строк, вида
{{32CEA158B6D90409E0530820A8C011BB:10}}, каждый из которых будет уникальным.
В простом случае даже можно себе представить что такой "обратный", "восстанавливающий" индекс - один - общий на все столбцы.
и имеет вид
{{32CEA158B6D90409E0530820A8C011BB:{name='Маша',age=10}}
(но это есть строчное представление в конечном счете)
Т.е. в такой системе хранимые значения задвоятся, а идентификаторы строк размножатся по числу полей.

битмап здесь при том, что число имен людей и и мощность множества их возрастов, выраженная в годах,
много меньше числа людей и может появиться желание перейти к более компактному представлению по отношению даже к сжатому
Вася:{32CEA158B6D90409E0530820A8C012BB,32CEA158B6D90409E0530820A8C013BB}
фиксируя местоположения идентификаторов встречающихся строк с именем Вася в некоторой битовой карте представляющей
разом все множество наличных строк.

а если захочется разные поля хранить в индексах различных систем устройства, то (к описателю поля) надо добавить знание о типе индекса, чтобы задействовать правильный алгоритм поиска в специфическом индексе.

как-то так я увидел твои намерения.
И задачу сформулировал бы так:

Можно ли придумать такую систему хранения (вероятно - граф некоего сорта),
которая была бы быстрой на поиске как b-tree индекс и универсальной по отношению к выбранному набору полей для которого
формулируется условие поиска. Для начала - безотносительно к сложности модификации данных на такой структуре.

Не знаю, на сколько это идея удачна, но, может быть, есть смысл посмотреть в сторону алгоритмов поиска на строках.
Подразумевая, что хранимая строка данных это буквально строка и ставится задача сопоставления против множества образцов.
Такой Ахо-Корасик, вживленный в инмемори субд.
(Деревья для таких поисков желательно простроить их начала)

Еще раз сорри - я не для поучать, а так - на поговорить заскочил, пока коньячок согревается.
А так мне менять позицию надо - вот уже и аромат из бокала выпирать начал - пора.


Для начала без учета проблемы модификации

booby,

авторТакой Ахо-Корасик, вживленный в инмемори субд.
впрочем, больше на на regexp похоже

mayton...
Пока дошел до того что нужен merge двух R/B деревьев. Или поддеревьев.

А как ты планируешь мержить свои деревья, если узел одного из них указывает на экземпляр значения 'Вася', а узел другого указывает на экземпляр значения '10'.
Карл, на что должен указывать узел дерева, полученного как результат слияния первых двух?