Люди вы о чем. ООП плохо ложиться на Реляционную модель, потому что таблички со детерминированными связями между ними хорошо реализуют инкапсуляцию, с наследованием и полиморфизмом слегка сложнее. Технически надо реализовывать ТВМ (VMT) и иже и логику работы с ними запихивать во вьюшки. Т.е. кому-то (програмисту или ORM) придется реализовывать их вместо нативной. Это резко добавляет накладных расходов.

U-geneПро такие высказывания и написано в стартовом посте "КМК проблема исключительно в зашоренности, которая проявляется в том, что объект пытаются так или иначе воткнуть внутрь одной таблицы (как строку, или как поле строки)."

Мы говорим о парадигмах ООП? В том числе об инкапсуляции?
Да технически это можно реализовать не впихивая в одно место, но тогда мы клали болт на ООП. Вопрос именно в том, что у реляционной модели одни подходы к представлению данных, у ООП другие. Внутре, объекты ООП представляют собой те же таблицы данных и методов. Но выглядит он для программиста единым целым.
Кроме того ООП делает вид, что позволяет иные связи между данными, чем сравнение только самих полей объектов - там идут в ход связи по метаданным.

U-gene Если думать внутри этих шор, то поневоле начнешь рассуждать о наследовании таблиц и т.п. непонятных мне вещах.

Вопрос в том и состоит, почему ООП плохо ложиться на Реляционную модель.
Он потому и плохо ложиться, что требует разных взглядов. Реализовать одно, через другое можно. Но и будет требовать выполнения той работы, которую обычно скрывает компилятор. И часть операций будет делаться не эффективно, ибо инструмент заточен на иное.

U-geneА если еще знать про Oracle, PostgreSQL и т.п. авторитетах, одевших те же шоры десятилетия назад, то, наверное, любые попытки думать в альтернативном направлении просто не воспринимаются, сознание упрямо впихивает объект в таблицу, и, как результат, видит проблемы, которые в альтернативе не существуют.
Упрямо впихивают пользователи. Ибо РСУБД относительно быстры и вездесущи. В том же Oracle можно хранить объекты. Правда это почти никому нафиг не сдалось.

Вопрос в том, что если не использовать механизмы навигации СУБД. А делать это на стороне прикладного приложения, то реляционная модель и вовсе не вперлась - используй СУБД пключ-значение и все пучком. Но может оказаться, что придется таскать кучу объектов для того, чтобы найти два связанных. И все придется делать самому. Вот все и хотят и рыбку съесть... Т.е. чтобы и СУБД работала на фильтрах и самому объектами вальяжно оперировать.