первый вариант подходит для реализации связей типа один к одномуПервый вариант ничуть не хуже подходит для реализации связей типа 1:M. Потребность в связях 1:1, скорее всего, говорит о проектных ошибках. Я во многом согласен с мнением Д.Лисеева, высказанном в дискуссии 3-летней давности.
Cache на рынке уже более 10 лет, технологии пора бы уже обрести зрелость. Вам не кажется, что за эти годы объектно-реляционный подход к проектированию БД так и не обрел крепкого теоретического фундамента, поэтому и пользоваться им весьма не просто?
На практике, в основном, встречаются 2 подхода:
Р) РСУБД + приложение, работающее с ней только через SQL
Приложение реализовано в зарегистрированных классах или даже в "рутинах". Т.е. отдельно данные, отдельно - программы. Программы могут использовать глобалы в "технических" целях, таких как временное хранение промежуточных данных.
ОО) ООБД полностью инкапсулирована в интерфейсные классы. Тогда уже неважно (для прикладного программиста), как она устроена, т.к. он с нею напрямую не работает, и всевозможные Relationship ему не подмога. Внутри интерфейсных классов работа с БД в этом случае может быть реализована даже на уровне глобалов - это уже вопрос реализации.
Плюсы и минусы Р-подхода:
+ можно полноценно использовать сторонние средства моделирования БД
+ можно использовать какие-вам-нравятся подходы к программированию приложения.
- пресловутый impendance mismatch.
Плюсы и минусы ОО-подхода:
+ потенциально - более высокое быстродействие
+ большая защищенность БД от ошибок прикладных программистов
- сложнее "добыча данных" из такой системы по инициативе сторонних программ.

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

А может просто использовать...Все вышенаписанное основано на практике использования, это не измышления. Если нужны конкретные примеры, их есть у меня :) А вот есть ли примеры успешного использования ОР-подхода? Честно говоря, сомневаюсь. Дискуссия "о 3-х инсертах" в соседнем топике меня лишний раз в этом убеждает.

Отличный пример: писать web-приложение можно по-разному. Можно напрямую работать с БД из js-кода, используя возможности CSP, а можно инкапсулировать работу с БД в серверные методы.

doublefintэтим нельзя пользоваться?Именно. Представьте, что это авторы-книги. У 1 автора м.б. несколько книг. У 1 книги - несколько авторов. Пока все хорошо :) Но вот вы решили удалить из БД книгу (ошибочно введенную, например, да мало ли по какой причине). Как вы это сделаете? Не удалив всех ее авторов, вы книгу не удалите.
Введя промежуточный объект (e.g. "авторство"), связанный с книгой и с автором отношениями 1:M, мы эту проблему снимаем. Если продолжать использовать Relationship, то удаление книги потребует предварительного удаление всех дочерних "авторств" - но не авторов.
Сторонники "чисто объектного" подхода хотели бы, чтобы связь выступала как отдельная сущность (хотя и нехорошо так ее называть :), которая может иметь атрибуты и т.д. Но мне кажется, что это не принципиально - нагрузить атрибутами промежуточный объект (таблицу), или саму связь.