Здравствуйте.

Задумка следующая.
Планируется БД, описывающая большое число сущностей.
У всех них есть определённые свойства. Но формализировать эти свойства на этапе проектирования БД невозможно.

Т.е. имеем что-то навроде

Сущность1- свойство1-true, свойство2-"агрессия"
Сущность2- свойство1-true, свойство3-135
Сущность3- свойство4-"параллелепипед"
Сущность3- свойство2-"гипноз", свойство5-0,425

т.е. записи в БД обладают каждая своим набором характеристик. Только вот какие будут эти наборы, какие будут характеристики- неизвестно. В то же время параметры будут неуникальными, и одним и тем же параметром будут обладать много записей. 

Думаю пока вот что:

Для каждого свойства в процессе работы БД создавать свою таблицу:
ID: integer
MotherTable: VarChar
RecordInMotherTable: integer
Value: - по обстоятельствам.


Во время запроса необходимо обращаться к этим таблицам. А вот как... 
У кого какие варианты? Использовать rdb$relations.rdb$relation_name ? 

Чтобы узнать, какие вообще свойства описаны для данного объекта, думаю использовать связанный список... Ну, в любом случае, это ещё одна таблица, возможно несколько. Нахрапом пока больше ничего на ум не приходит 

Но у меня стойкое ощущение, что я изобретаю велосипед... 

Итак, резюмируя:
Как строить запросы к таким таблицам?

Вот так?:

Select (подзапрос) from (подзапрос) where и т.д. с подзапросами?
Кажется, как-то громоздко...

P.S. В БД необходимо осуществить объединение логически не связанных объектов и свойств. Скажем, круглый вишневый стол, гроза над Мурманском и цитаты из книг Кастанеды  Причем свойства объектов и их количество, равно как и количество объектов на этапе проектирования неизвестны и объективно не могут быть получены. 

P.P.S. Расписал всё с тайной мыслью- вдруг кто делал то же, и есть какие-то другие идеи?

и медленно