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

Эту задачу в ORM популярных выполняет Identity Map. по сути. Оно гарантирует тебе что ты достал ряд из базы и этому ряду соответствует конкретный инстанс объекта.

условно представь себе простой кейс - ты выбираешь из базы комменты и их авторов. И у тебя авторы будут дублироваться, и это дублирование тебе надо явно замэпить на конкретные инстансы объектов что бы целостность была на уровне in-memory структур данных.

Во всяком случае это важно если ты собираешься потом менять стэйт авторов каких-то. Что бы не вышло так что у тебя два инстанса объекта представляют собой одну и ту же сущность (одну и ту же identity) и потом разруливать что у тебя два варианта стэйта этой сущности.

на чтение скажем мы можем игнорировать все эти сложности и работать с копиями объектов. Если мы не планируем ничего менять то и рисков "неконсистентности" это не пораждает.

вот это "дублирование" (денормализованный result set) это то что может пораждать ту самую двусмысленность о котороый ты спрашивал ранее. Мол у меня есть два инстанса с одной айдишкой, у них разный стэйт, кому верить кому нет?

Так понятнее?

"... с одной и другой стороны."
Одна таблица ссылается на другую?
Или app/база?

вот есть у тебя табличка comments. там есть author_id. Значение для этого поля хранится в comments. И есть условный users у которого есть user_id который так же хранит в себе значение.

То есть мы "связь" тут не на уровне данных (не референсы и не пойнтеры) а чисто логическая которую ты можешь усилить задав foreign key и тогда за ссылочную целостность будет отвечать СУБД.

Но когда ты делаешь

SELECT c.text, u.username, u.id FROM comments c INNER JOIN users u ON u.user_id=c.author_id

то у тебя в резалт сете условном будет

| text              | username      | id |
| твой код говно    | Bob           | 4  |
| нет твой код говно| Martin        | 8  |
| поговори мне еще  | Bob           | 4  |

и тебе надо как-то это недвусмысленно замэпить на структуры данных так что бы по итогу объектов "Author" было не 3 а 2, нормализовать резалт сэт по сути. Вот именно эту проблему решают ORM.

Понял.

Спасибо 👍

сегодня с учетом того что многие СУБД поддерживают документы (jsonb какой) то можно весь агрегат и все еге составные части хранить в одной табличке. Если у нас "агрегаты" эти не пересекаются (нет ленивых связей которые мы для UI лепим), если  у тебя хорошо все с границами транзакций (мы не достаем рандомом объекты и не меняем их что б потом делать diff всего стэйта, как гибернейты делают и прочие глобальные unti of work имплементации) то эта проблема не так остро стоит и вся это тяжелая и сложная инфраструктура для поддержания ссылочной целостности не так уж и нужна. Не говоря о других моделях данных используемых сегодня.

на чтение никто не мешает "забить" на этот impedance missmatch и просто дублировать данные. Можно даже на уровне SQL делать за счет всяких json агрегаций все преобразования.

Понял.

Всегда ли на первом месте при адекватной разработке ПО стоит предметная область?

Ммм... Философский вопрос но да проблема диктует решение

Да не. На вордпресе вон настройкой готовых решение занимаются.

Но ведь кто-то сначала эти решения написал.

имеются в виду только комерческие проекты?

Так вопрос же не об этом был.

Энтепрайз и тд...

Хотя в любом случае главное предметная область, что может быть ещё?