Leonid Kudryavtsevпочитал
http://rxo-project.com/wp-content/uploads/2013/03/GrigorievOnImpedanceRU.pdf

мне, в принципе, идея понравилась. Не очень понятно, насколько востребовано в мирных целях, но сильно бредовой не выглядит.

Читал наискось, не вникая. Как я понял, главная идея разобрать классы по атрибутам, а потом "собрать" их обратно из получившегося хлама.
(или реализуем атрибут как STORED, или как отношение SELECT, или как процедурный код )

В общем, IMHO вполне жизненно. По крайне мере, как замена EAV.

Ну и в эпоху популярности скриптовых языков, вполне может найти своих поклонников.

ты все неправильно понял. прочитай статью еще раз.

автор (страдающий натужным словесным недержанием) сначала доказывает, что между ОО и реляционной моделью прямое соотвествие (а чего бы его там не было, 1:M, M:1 и там и там, отличается лишь реализация), а в конце скатывается к тому, что уже десятки лет назад пытались срелать в ОО базах данных (тот-же Oracle) - расширить синтаксис SQL, чтоб можно было джойнить через точку, писать нечто вроде SELECT document.contract.contract_date FROM document
вместо SELECT contract.contract_date FROM contract, document WHERE document.contract_id = contract.contract_id

Leonid Kudryavtsevвадятвои разделения - правильные, но страдают одним - описывают крайности. истина всё же по середине...
надо использовать и оба подхода даже в одном проекте, главное добиваться качества системы, а не следования кем-то придуманных принцЫпов.
тогда и удав счастлив и и ёжик бегать в тумане.

Просто не надо пытаться впихнуть в невпихуемое

Я так взъелся именно из за попыток ООП в реляционный SQL (Query Language) впихнуть. Даром он там не нужен. Использовать ООП в языках программирования, в общем то, никаких проблем. (хоть pl/sql, хоть java).

Из всех ООП расширений, максимум денормалиция результатов запроса (агрегировании нескольких наборов данных в одно поле) как костыль, для уменьшения трафика межу приложением и БД. Все остальное IMHO не жизнеспособный шлак.

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

Если уж хочется скрестить ООП и БД, то тогда логичнее кажется брать/делать сетевую СУБД. Давать доступ к информации как к стримам, передавать в СУБД лямбду, получать результат. Только с существующими РСУБД такой финт ушами вряд ли пройдет.

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

а отдельно взятые "чистые" OORDBMS оказались и вовсе никому не нужны - никому не охота отлавливать глюки в продакшине аля Иллюстра, надежность важнее синтаксиса.

U-genedbpatch,
Вы либо статью не вчитали, либо с Ораклом и тд не знакомы. В оракле "таблица = классу" и "структура объекта класса = схема таблицы". Нафига такие классы, которые почти таблицы- не очень понятно. В статье же предлагается строить классы из типов, допустимых в РМД (т.е. из скаляров и отношений), а таблицы, наоборот, из типов доступных в ОО части (скаляры и ссылочные типы(тоже скаляры)), т.е. строго "таблица != класс" (про это еще Дейт много писал, но он шел только в одну сторону, от скаляров к таблицам). Кроме того, там по ссылкам есть статьи, где строго доказано, что система построенная по этому принципу остается строго реляционной. В при этом классы и таблицы могут сосуществовать в единой схеме данных, т.е. в RxO можно строить сложные гетерогенные схемы данных, гораздо более выразительные, чем просто табличные (как сейчас в современный РСУБД).

Вообще, такой невдумчивый дилетантизм "вот оракл 20 лет назад с объектами ковырялся, у них ничего не получилось, значит и тут - фигня" - очень большая проблема, и каждый раз заново разницу приходится разжевывать.

честно говоря, я даже задумался, о чем ты сейчас. скаляры, ссылочные типы, строго реляционной?
ты еще про функциональные зависимости, кортежи и 5НФ задвинь, чтоб туману побольше напустить, обчитавшись Дж.К. Дейта

мысль твоя в чем?

я три раза перечитал твой опус - понял только одно - ты чем-то глубоко возмущен, но незадача - мысль твоя (что именно ты пытаешься доказать) - так и осталась неочевидной.

таблица != класс? ну ясен пончик, в одну таблицу можно материализовать все множество порожденных классов, а можно и вовсе eblobы в JSON запихнуть, и дальше что?

а так там в статье много чего понаписано, из отряда когнитивных диссонансов автора

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

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

U-geneА все. что Вы называете словесным недержание - описание понятий, нужное, что бы прийти к этому выводу. Но если в голове это не получается удержать, то это не проблемы статьи.

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

а он первые три листа несет какую-то пургу из намека на проблематику, и даже не пытается четко обозначить суть решаемой проблемы и собственно решение, дочитав до четвертого листа уже трудно вспомнить, о чем речь начиналась

хорошо хоть абзацы пытается ставить (не к месту)

если бы не примеры в конце - статью и вовсе можно было бы отправить в треш как бессмысленную компиляцию фраз