ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Зачем ER? Делаете классы и связи между ними и вот вам ER. А по ней автоматом генерируется схема, если она вообще нужна вашей СУБД.
Разве не так все работают?

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

В итоге можно легко получить БД которая даже первой нормальной форме не соответствует. К примеру люди добавляют в БД человека и вкладывают в него данные о документах или данные о том где он живет.

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

Дополнительно очень часто такой подход рождает не оптимальные запросы к БД так называемая проблема N+1...

… решаемая в EF уж тремя разными способами (проекции, eager loading и explicit loading)

В смысле стандартов C и C++, кстати, указатель как раз объект — хранящаяся по какому-то адресу значение (адрес чего-то другого).

Это какая-то совсем чёрная магия. Для контроля типов и составления контекстной подсказки сгодится, но какое ожидать поведение от таких объектов?

doctrine-migrations (кстати, не является частью DoctrineORM) генерирует скрипт миграции на PHP, в котором чистый SQL конкретной версии конкретного диалекта SQL.

По-моему даже с точки зрения теории множеств можно описывать объекты по разному.

Термины логика и отношения перегружены разными смыслами. Вы кажется говорите про онтоллгии. Здесь же имееются ввиду отношения как в логике счисления предикатов — конъюнкция, дизъюнкция и вот это все. Реляционная алгебра это по сути обобщение ЛСП на множества, что позволяет оперировать не отдельными утверждениями, а сразу пачками подобных (отношениями).

Засада с ORM в том, что когда мы говорим сохранить объект в базу, то имеем ввиду сохранить нечто логичное в терминах ER, но нелогичное в терминах ООП. В ООП объект это в первую очередь поведение, состояние которого напрочь скрыто от внешнего наблюдателя (инкапсулировано). Поведение описывается программой. Но сохраняя объект мы не сохраняем базу поведение, а как раз вот это самое неведомое состояние.

ORM сочетает принципиально разные вещи. Поэтому тут нет универсального подхода. В зависимости от решения, эти модели могут как органично дополнять друг друга, так и страшно неудобно конфликтовать.

Например, в объектной модели у класса Order(заказ) есть свойство типа массив lines со строками заказа типа товар+количество. В объектной модели строке ссылка на заказ не нужна, как и идентификатор самой строки (достаточно индекса строки в массиве). Не во всех SQL базах вы сможете напрямую создать в таблице order столбец lines, являющийся упорядоченным множеством пар [itemId: quantity], а если сможете, то работать с ним будет неудобно, могут, например, отсутствовать возможности полноценной индексации такого поля, да и условие типа SELECT * FROM order WHERE EXISTS(order.items.itemId = 10523) вряд ли напишите.

Скорее всего вы создадите таблицу order_items, может с суррогатным PK, может с составным [orderId, index], причём эти колонки будут в любом случае, и скорее всего суррогатный id и поля orderId и index будут в вашем объекте, хотя на уровне объектной модели они вам не нужны вообще. Протечка реляционной модели в объектную налицо.

Представить можно, что угодно, но зачем представлять себе таблицу в базе данных? Не, для задач типа phpMyAdmin так и надо представлять. Но если мы пишем прикладное приложение, где есть понятие "пользователь", почему не надо его выражать объектом? То, что состояние этого объекта сохраняется в базе данных всем, кроме разработчиков и админов, всё равно по сути.

М.б. имеется в виду контроль единственности не объекта, а класса?

По факту разница для прикладного разработчика в том, что в рамках одного процесса мы можем устанавливать идентичность двух объектов по ссылке. А для разработчиков ORM использование IdentityMap позволяет в большинстве случаев переложить ответственность за изменения БД на прикладного разработчик. Если он перезаписывает свойства заведомо одного и того же объекта несколько раз в разных частях приложения, то не должен удивляться, что в базу запишется только последнее значение на момент вызова save или flush. А если отдавать разные объекты, то разработчика ORM придётся разруливать конфликты.