Funny_Falcon
Я не супер программист. Но думаю, что этот вариант все равно лучший. В постгрессе есть
индексы по выражению и условные индексы (и их сочетание). Их применение могут дать
удовлетворяющий вас результат...

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

И куда там пристроить индексы по выражению и условные индексы (и их сочетание)?

Заранее благодарна.

2 Funny_Falcon
Спасибо, очень интересно.

Ну, в общем-то, я уже прошла тот уровень, о котором Вы говорите. Запрос у меня всегда возвращает только набор ссылок (ну, коллекцию объектов, в Вашей терминологии, если я Вас правильно поняла) на нужные мне объекты, без значений атрибутов.
Значения атрибутов я получаю "потом", по мере обработки данных (например, при отображении - скроллинг списка документов вызывает динамическую подгрузку значений нужных мне атрибутов и т.д.), однако проблема вовсе не в этом.
Основная проблема в том, что выборку (коллекцию объектов) приходится формировать, исходя из значений этих "виртуально-динамических" атрибутов. Естественно, это все выполняется в процедурах на сервере, исходя из значений Словарей Данных, а там уже одним единственным Join не обойтись (скажем более корректно - я не смогла обойтись).
Индексы в работе у меня практически не используются (ну, естественно, индексы первичных/внешних ключей все же используются :) ), так как в дизайн-тайме состав нужных атрибутов неизвестен, заранее неизвестны структуры запросов, и, следовательно, неясно, по чему строить индексы. Конечно, значения информационных полей в служебных атрибутах-справочниках проиндексированы, что несколько улучшает картину, но выборки часто строятся по сложным условиям, и выборка выполняется без использования индексов.

К примеру, при формировании запроса на получении списка документов, сгруппированного последовательно по 3-4 атрибутам (что-то вроде псевдодерева), время реакции на такой запрос занимает до нескольких минут уже на объема 10-20 тыс. документов.
В то же время подобные запросы к "родным", жестко сформированным структурам выполняются около 0,3...0,5 секунд на объеме в 100 тыс. документов. (реально ожидаемая нагрузка - 40-50 тыс., требуемое время реакции на запрос - 2-3 секунды.)

Все данные - для сервера FireBird 1.5.2 (SS), почти все установки по умолчанию, на Windows XP Prof SP1, на машинке AMD Athlon 3.2 +, 512 RAM и т.п. (ничего особенно плохого/хорошего).
-----------
"Значения полей любого типа можно хранить в тексте." - и это было (есть). Эффективнее оказалось ограничиться несколькими простыми типами, хранимыми в разных табличках, чем выполнять преобразования типов в/из строки. Впрочем, вопрос спорный для различных случаев.
-----------
Все равно спасибо.

1. Рабочая база на FireBird, схема есть в ErWin (интересно было бы переработать с учетом возможностей PostgreSQL - я имею в виду наследование таблиц - но пока не нашла в ErWin такого. Может, как-либо, используя субтипы...).
В PostgreSQL еще не "рыба в воде". Пока осваиваю основы, пишу тестовые программки.

2. Еще рабочий вариант: гораздо более быстрый, но "некрасивый". В табличке создается избыточное число полей, назначение которых меняется динамически, самим пользователем. Все такие поля - физически типа Varchar (чтобы не так база "пухла"). Отдельно - словарь атрибутов, в котором указан тип (еще раз - логический, физически все Varchar) В FireBird с полями типа Varchar по сетке гонятся только фактические данные.
Отдельная табличка - список связей со справочниками (т.к. справочников также переменное число). Значения соотв. полей справочника физически переносятся в главную табличку.
Т.е. денормализация - дальше некуда. Даже триггеры есть специальные - при изменении значений в справочниках (и значения ссылки на элемент справочника) физически меняются значения отображемых атрибутов. Ужас, конечно, с т.зр. концепции нормализации - зато выборки очень шустрые.
Т.е. запросы выглядят не так:
а так, только к одной табличке Main:
Field_07, Field_08... - это физические имена полей, хранящих значения соответствующих полей справочников. (Сами логические справочники тоже подобную логическую структуру имеют)


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

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

3. Как легко догадаться, в обоих случаях довольно большая нагрузка как на сервер (ХП / триггеры), так и на клиента (интерпретация логической структуры в физическую и наоборот). Впрочем, основная нагрузка - на программиста. ::) PostgreSQL начинающий во многом прав.

3. Извините, схемы я Вам не вышлю. Самой нужно :).

5. Вспоминается анекдот: мужчине после автокатастрофы пересадили женские уши.

"Доктор, пожалуйста, отпарывайте обратно"
"Что, плохо слышите?"
"Слышу хорошо: не понимаю ничего."

(Это так, к слову)