Здравствуйте, bkat, Вы писали:

B>Это может рассматриваться и как достоинство.
B>Хранить данные лучше отдельно от их интерпретации.
B>Сегодня ты можешь данные проинтепретировать одним
B>образом и сделать одни выводы, а завтра — совсем иначе.
B>Данные же останутся одними и теми же

Есть обработка данных, а есть интерпретация. ;-)
В основе любой задачи лежит Модель Предметной Области (ПО), в не зависимости от того как она реализована.
Реляционные СУБД хранят только фактические данные о ПО, Объектные СУБД в основе хранят только информацию об Объектах ПО. Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации.
Для простых задач способ представления и хранения информаци не критичен, для сложных (сильно связанных) задач без "правильного" (соответствующего действительности, а не текущего взгляда на проблему) представления информации нельзя создать устойчивую к изменениям систему — приходится постоянно модифицировать исходные структуры данных. Если же использовать соответствующие семантические принципы описания информации, то можно оперировать уже абстрагированными понятиями, что делает решение задачи инвариантным к изменяющимся условиям. (О-как ;-)

P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).