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

Любое мнение имеет право на жизнь. Даже неаргументированно-рефлекторное.

PS А что - не помойка?

2 мод

Вы бы все же прочитали, о чем вообще речь. Где Вы у меня, например, таблицы нашли?

модНельзя манипулировать отношениями - объекты попортишь. Следовательно не имеет никакого значения, на какую СУБД транслировать - хоть на сетевую. Все равно на уровень СУБД пользователь никогда не выйдет, останется на уровне объектов
1) под манипуляциями я впервую очередь имел запросы. запросы не изменяют данные. идея в том, что к данным множества сложных объектов можно применять групповые операции РМД (это не INSERT не UPDATE и не DELETE) безо всяких танцев с бубном.
2) можно и изменять. Точнее пытаться изменить. Далее зависитот того, как объект реализован, может он и не "захочет" изменяться
3) для изменения объектов более подходит вызов методов. Тоже групповой. Почему и как оно сработает следует из некоторых свойств РМД.
3) "почему" и "как" - пересказывать две статьи не буду.

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

Опять таблицы .

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

модИ по прежнему непонятно, почему РМД а не например сетевая, иерархическая или мумпс. Транслятору-то все равно во что транслировать.

Во -первых поэтому
Во вторых - сочетание ОО и РМД гармонично :) Я имею в виду. что тип "отношение" и его свойства никуда не деваются (потму как ежели в ОО системе тип задан, то им можно пользоваться как хочешь), и, в свою очередь, свойства типа "отношение" делают возможным групповую работу с объектами безо всяких итераторов.

2 MasterZiv
Далее читать не имеется желания.
Дело хозяйское. Там в обсуждении на citforum'e пара человек отметилась - мне уже достаточно :).

На всякий случай - там в начале ссылка на статью, которая послужила поводом (но не причиной) написания сабжа. Может там про импеданс найдете? А вообще с явлению, обозначаемому термином "impedans mismatch", я несерьезно отношусь. Наверное поэтому так несерьезен и с самим термином.

Вчитался внимательно в описание ODMG стандарта. Связи только бинарные :). Сразу почему-то вспомнил про ЧАЛа.

В общем, возьмите Третий манифест, почитайте, что Дейт пишет про ODMG. Еще до начала сопостовления ODMG и предложений ТТМ, Дейт находит кучу неопределнностей и внутренних противоречий.

Вариант на английском . Названием поменял.

Хобби у меня такое странное.

пытаться описать сложную тему еще более непонятными словами?
согласен, слова "значение" "перменная" "тип" "операция" сейчас относятся к непонимаемым.

комментарий Сергея Кузнецова, на мой взгляд очень грамотный
Согласен. Именно поэтому в англ. версии я
1)поменял название (в самом деле "безимпедансный" подразумевает налииие полного соттветсвия из чего следует наличие наличие нескольких частей, между которыми это соответсвие существует - а в моем случае таких частей нет)
2) в последнем варианте убрал нафиг главку "Могут ли существовать ОО мдоели данных". Это вовсе не означает, что я отказался от своих мыслей по этому поводу и у меня зреет статья, где я разжую эту мысль подробнее (например, СДК в своих замечанниях на равных употребляет применительно к системам термины "объектная" и "объектно-ориетнированная" но КМК это немного разные вещи)

В общем, после этих изменений, сделанных в связи с замечаниеми СДКузнецова, от них останется (и КМК это немалого стОит)
1) "ряд мыслей, с которыми я полностью согласен"
2) "фактически предлагается новый подход к построению объектно-реляционного отображения" (с чем я в общем то согласен - если, конечно, рассматривать термин "отображение" в самом общем виде - например трансляторы могут быть названы системой отображение структур, возможных в транслируемом языке, в структуры, возможные в языке, на котором записан результат трансляции)
3) "Но полностью закрывать глаза на объективно существующие технологии и предлагать подходы, в которых не учитывается их существование, нерационально и неправильно".Ну а я и не закрываю. :) Просто некогда писать это всё.

Да, отвечал много раз :)

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

Как аналогия - когда ты создаешь объект С++ в памяти и меняешь его,ты же ведь фактически сразу меняешь состояние этой памяти. То есть объект - это некое эфемерно-логическое образование, возникающее в твоем сознании за счет того, что ты используешь некий язык, который позволяет с этим образованием так же эфемерно-логически работать. Но не самом деле ты работаешь с памятью - потому, что инструкции С++ транслируются в команды работы с памятью. Объекты - это и есть память (только представленная эфемерно-логически по-другому).

Так же и RxO (только по отншению к записям РБД). Объекты RxO - такие же эфемерно-логические образования. РСУБД можно рассматриватется как машина, как компьютер. И как любым компьютером, можно ею пользоваться напрямую, а можно в ней же написать транслятор ОО-языка. Это и будет RxO система. И когда некоей командой мы меняем состяние RxO объекта, то эта команда, после трансляции, сразу, напрямую меняет записи таблиц. Любой запрос к RxO-объектам и классам траслируется в обычные запрос(ы) к таблицам. Более того, у меня получается, что любая последовательность команд может быть так оттранслирована, что за однин прием мы сразу можем обработать множество объектов - безо всяки явных или неявных итераторов. И все потому, что RxO объекты - это и есть совокупность записей таблиц (только представленная по-другому).

В общем, если принципиально, то КМК RxO дальше от O/R маппинга - в прикладном смысле этого понятия - чем, например, от SQL. Однако в общем смысле любой транслятор, как я уже писам, - это средство маппинга. Но без переноса данных.