Здравствуйте, IT, Вы писали:

IT>Исторически DAL и прочие ORM появились как адекватный ответ на проблему типизированной работы с источником данных, точнее с отсутствием типизации. Некоторые решения остановились на минимально необходимом решении самой проблемы, некоторые пошли дальше, предлагая полную абстракцию от источника данных, используя в качестве такой абстракции объектную модель приложения. В результате мы имеем следующую модель взаимодействия: приложение <-> объектная модель <-> источник данных (включая его модель).

Проблема ОРМ-ов еще и в том, что они вместо простого отображения из системы типов СУБД в систему типов ЯП навязывают идеологию "прозрачности". Я не знаю где это зародилось, но уже в CORBA и EJB разговор велся не об отображении данных СУБД в данные ЯП, а об прозрачной персистентности данных. Я долго не мог понять, что означают слова вроде "объект живет дольше программы". Потом осознал. ОРМ-ы пытаются сохранить состояние программы, а не упрощают обработку данных в ней. Но такой подход вызывает следующие проблемы:
1. Памяти приложения недостаточно для хранения всех объектов в памяти, а значит требуется механизм виртуализации — подкачки и сбрасывания объектов из систем персистентного хранилища (исходно они не обязательно были БД).
2. ООЯ и ИЯ не имеют выразительных средств обработки массивов данных представленных в объектной форме.

Эти проблемы приводят к тому, что код написанный на базе таких персистеров становится не эффективным и громоздким.

Здравствуйте, IB, Вы писали:

ANS>> Т.е. конвертация данных в объектную модель — цель существования ORM.
IB>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.

Точнее сказать эта работа не реализуема эффективно сама по себе и приводящая к использованию технологии обработки данных которая так же крайне не эффективна.

Собственно современные ОРМ-ы имеют средства поднятия производительности — объектные запросы. Вот только на сегодня не ясно, а зачем тогда все остальные функции ОРМ-ов и зачем тогда сами ОРМ-ы, если запросы можно делать прямо к БД (если она управляется SQL-СУБД)?
Единственный ответ который я вижу на сегодня — это упрощение тех самых запросов за счет устранения (или минимизации) соединения (join) таблиц/коллекций. Однако как раз linq с успехом и очень просто решает эту проблему.
На мой взгляд, linq-у нехватает только наличия удобных DML-операторов (аналогов INSERT, UPDATE, DELETE из SQL) и системы сменных провайдеров.

Здравствуйте, Cyberax, Вы писали:

IB>>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
C>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

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

Здравствуйте, Cyberax, Вы писали:

C>RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

C>Просто так получилось.

Фундаментальная причина — отсутствие мат.модели объектного хранения данных. ООП был создан для симуляции объектов реального мира в памяти компьютера. Первый ООЯ так и назывался — Симула. Другое ответвление — Смолтолк, что не говорили бы его сторонники, ничего нового в ООП не привнес. Это все то же стимулирование объектов реальной жизни в той же памяти компьютера.

Вот Лисп появившийся примерно в то же время, что и Симула имел под собой стройную мат.модель — лябда-исчислений Черча — которая, в купе со списками, отлично ложится на реляционную модель. Как результат в Лисп-программах с самого начала не нужно было создавать костылей подобных ОРМ-аперам.
Не прошло и 50 лет, как это было замечено в Майкрософт и применено на практике.

Здравствуйте, Cyberax, Вы писали:

IB>>Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.
C>Ну и причём тут OODB, в котором всё точно такое же возможно?

У меня один вопрос. Можно? Спасибо!

Так в чем тогда заключается объектность БД если в ней я точно так же описываю список содержащий позиции заказов и потом как-то там связываю конкретные заказы с входящими в них позициями? Зачем мне для этого объектность? Мне кортежей за глаза хватит! Ну, может для упрощения можно кортежи поименовать и получить стркутуры а-ля С, за неимением которых, скажем в C# мы используем классы. По сути классы в таком подходе — это именованные кортежи.

Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?

Здравствуйте, Cyberax, Вы писали:

IB>>Затем, что прикладная логика существенно многообразнее того, что нужно хранить, и меняется эта логика гораздо чаще сохраненных данных. Собственно с чего и начали — это фундаментальная разница, между собственно данными и их интерпретацией в конкретном юзкейсе конкретного приложения. "Data != Object" (c)
C>Ну и причём тут ORM? В объектах, с которыми работает ORM логики быть не должно. Так что пусть себе меняется.

ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?

Здравствуйте, Gaperton, Вы писали:

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google. Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB, особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают. Сейчас — они поднимаются по хайпу, скоро будут на пике.

G>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее, практически весь геморрой, знакомый по RDB, отсутствует by design. Сочетание чрезвычайной простоты, и одновременно — большой гибкости. Обрати внимание, там чрезвычайно простая модель, много времени не займет. За полчаса будешь знать все. И не надо мне говорить про то, что там все запросы делаются через REST, а это медленно . К модели данных это не относится, а CouchDB демонстрирует пока только потенциал технологии.

Заметь:
1. Это технология предназначена скорее для структурированного хранения документов (т.е. конкурент XML, а не СУБД и ОРМ-ов).
2. В отличии от идеологии ОРМ-ов она так же как и SQL-СУБД использует запросы для обработки данных, а не навигацию по объектам (хотя казалось бы документы обычно представляются в виде дерева с одним корнем).
3. На сегодня это опять же не конкурент СУБД, так как она пока находится в исследовательской стадии. Посему преимущества от нее получают только исследователи, которые рискуют, так как вероятность неудачи велика.
4. Указанная реализация динамически типизирована и использует яваскрипт в качестве языка описания данных. Это вряд ли удовлетворит тех кто привык работать со статически-типизированными данными.

Здравствуйте, IB, Вы писали:

M>>скорее DSL, на крайний случай fluent-interface.
IB>Так ведь SQL существенно больше DSL напоминает, чем императивный шарп.

Кроме того DSL это уж точно нечто более высокоуровневое чем работа с объектами. И DSL можно навернуть как поверх ООП, так и поверх реляционных данных. DSL же будет описывать или сами данные, или их обработку.

Здравствуйте, VladD2, Вы писали:

C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.
VD>Под ними лежит стройная математическая модель и эффективная реализация (возможная, от части, из-за наличия мат.модели). А вот ОРМ-ы ничем подобным похвастаться не могу. Да и работают они как раз по верх тех самых "тупиковых" РБД.
Что в ORMах ты собираешься описывать теоретически? Язык запросов в той же Hibernate является реляционно полным, это несложо доказать формально.

Здравствуйте, VladD2, Вы писали:

C>>Ну и причём тут OODB, в котором всё точно такое же возможно?
VD>У меня один вопрос. Можно?
Нельзя.

VD>Спасибо!
Пожалуйста.

VD>Так в чем тогда заключается объектность БД если в ней я точно так же описываю список содержащий позиции заказов и потом как-то там связываю конкретные заказы с входящими в них позициями?
Собственно, практически ничем. Кроме того, что элементы кортежей являются типизированным и структурированными.

А типизированный и структурированый элемент — это и есть объект.

VD>Зачем мне для этого объектность? Мне кортежей за глаза хватит! Ну, может для упрощения можно кортежи поименовать и получить стркутуры а-ля С, за неимением которых, скажем в C# мы используем классы. По сути классы в таком подходе — это именованные кортежи.
Да.

VD>Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?
Не совсем. Обычно под ООБД понимается система, в которую объектность интегрирована. Оракул такому требованию не отвечает (если забыть на время про его объектные таблицы).

Здравствуйте, VladD2, Вы писали:

C>>Ну и причём тут ORM? В объектах, с которыми работает ORM логики быть не должно. Так что пусть себе меняется.
VD>ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?
Примерно так. Ну и представление ассоциаций в виде коллекций.

Здравствуйте, VladD2, Вы писали:

VD>Фундаментальная причина — отсутствие мат.модели объектного хранения данных. ООП был создан для симуляции объектов реального мира в памяти компьютера. Первый ООЯ так и назывался — Симула. Другое ответвление — Смолтолк, что не говорили бы его сторонники, ничего нового в ООП не привнес. Это все то же стимулирование объектов реальной жизни в той же памяти компьютера.
Мат.модель для отображения объектов на RDB есть — это реляционная алгебра. Тут ничего нового для OODB не требуется.

Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.

Здравствуйте, Cyberax, Вы писали:

VD>>ОК. Но тогда объясни мне разницу между твоими "объектами без поведения и логики" и кортежами РБД? Не уж-то вся разница в том, что ты используешь вместо join-ов синтаксис с точкой?
C>Примерно так.

Тогда спор снова ни о чем, так как ты используешь не сам Кибернэйт, а его подмножество во многом пересекающееся с LINQ-ом (окромя того, что Кибернэйт не поддерживает интегрированных в язык, типизированных запросов).
Суть же Кибернэйта несколько шире, как я понимаю. Вот цитата из описания Кибернэйта в Википедии:
http://ru.wikipedia.org/wiki/Hibernate_(библиотека)

Основные возможности

Целью Hibernate является освобождение разработчика от значительного объёма общих задач программирования по обеспечению сохранности данных (persistence — сохранность данных после прекращения работы программы). Разработчик может начать использовать Hibernate в процессе разработки как с нуля, так и для уже существующей базы данных.

Hibernate не только заботится о связи Java классов с таблицами базы данных (и типов данных Java в типы данных SQL), но также предоставляет средства для автоматического построения запросов и извлечения данных и может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL и JDBC кода. Hibernate генерирует SQL вызовы и освобождает разработчика от ручной обработки результирующего набора данных и конвертации объектов, сохраняя приложение портируемым во все SQL базы данных.
...

Явный упор на persistence, а не на mapping. Не правда ли?
Ежу понятно, что Hibernate можно использовать и как чистый мапер, но это слишком узкое применение. И вряд ли кто-то на нем останавливается.

C>Ну и представление ассоциаций в виде коллекций.

Это и LINQ2SQL с успехом делает.

Здравствуйте, Cyberax, Вы писали:

VD>>У меня один вопрос. Можно?
C>Нельзя.
C>Пожалуйста.
Вы батенька определитесь все же...

VD>>Так в чем тогда заключается объектность БД если в ней я точно так же описываю список содержащий позиции заказов и потом как-то там связываю конкретные заказы с входящими в них позициями?
C>Собственно, практически ничем. Кроме того, что элементы кортежей являются типизированным и структурированными.

Э... Почти все известные мне SQL-СБУД хранят данные типизированно. Все эти varchar(max)/varchar2, int и т.е. — это, что по-твоему, не типы?

Структурированность в РБД — это реляционные отношения и нормализация данных. Так что она тоже есть, но выглядит по другому. Как правильно заметил Ваня реляция позволяет описать отношения данных, а конкретные иерархии строить для конкретных задач.

Может быть речь о наличии вложенных структур? Скажем Оракл позволяет делать вложенные структуры данных в столбцах. Но ты же его не называешь ООБД? Почему?

Или что тогда скрывается за этим термином "структурированными"?

C>А типизированный и структурированый элемент — это и есть объект.

Это, извините, батенька чушь несусветная. В классическом процедурном Паскале были записи. В классическом фунциональном ML-е записи и кортежи. Все эти типы структурированы и статически типизированы, но они не объекты и даже не классы! Это просто комплексные типы данных. Причем кортежи еще и имен не имеют. Кортежи вообще 1 в 1 повторяют описание строк таблиц БД (да и по сути родились из единой теории).

VD>>Зачем мне для этого объектность? Мне кортежей за глаза хватит! Ну, может для упрощения можно кортежи поименовать и получить стркутуры а-ля С, за неимением которых, скажем в C# мы используем классы. По сути классы в таком подходе — это именованные кортежи.
C>Да.

Если ты со мной согласен, то лично я делаю вывод, что ты целиком на нашей стороне, просто путаешь терминологию. Но тогда я не пойму что ты нашел в этом Кибернейте?

VD>>Эдак и Оракл является ООБД, так как позволяет хранить именованные "объекты", а не не именованные — кортежи. Не так ли?
C>Не совсем. Обычно под ООБД понимается система, в которую объектность интегрирована. Оракул такому требованию не отвечает (если забыть на время про его объектные таблицы).

А в чем разница то? Хоть убей не вижу из твоих рассуждений. Ведь если мы пользуемся только POD-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная. А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.

Здравствуйте, Cyberax, Вы писали:

VD>>Фундаментальная причина — отсутствие мат.модели объектного хранения данных. ООП был создан для симуляции объектов реального мира в памяти компьютера. Первый ООЯ так и назывался — Симула. Другое ответвление — Смолтолк, что не говорили бы его сторонники, ничего нового в ООП не привнес. Это все то же стимулирование объектов реальной жизни в той же памяти компьютера.
C>Мат.модель для отображения объектов на RDB есть — это реляционная алгебра. Тут ничего нового для OODB не требуется.

Реляционная алгебра — это мат.модель лежащая под РСУБД. Она ни какого отношения к ООП не имеет. Более того. В ней даже терминов "объект" или "класс" нет.

C>Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.

ООБД не могут пользоваться реляционной алгеброй хотя бы потому, что в итоге получится РСУБД .

И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки. А вот СУБД с движком на основе ООП я почему-то не видел. Плохо смотрел?

Здравствуйте, VladD2, Вы писали:

C>>Мат.модель для отображения объектов на RDB есть — это реляционная алгебра. Тут ничего нового для OODB не требуется.
VD>Реляционная алгебра — это мат.модель лежащая под РСУБД. Она ни какого отношения к ООП не имеет. Более того. В ней даже терминов "объект" или "класс" нет.
В ней есть термин "кортеж". Классы банально преобразуется в кортежи, а дальше всё просто.

C>>Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.
VD>ООБД не могут пользоваться реляционной алгеброй хотя бы потому, что в итоге получится РСУБД .
Так и получается.

VD>И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки.
Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.

Здравствуйте, Cyberax, Вы писали:

C>>>Мат.модель для отображения объектов на RDB есть — это реляционная алгебра. Тут ничего нового для OODB не требуется.
VD>>Реляционная алгебра — это мат.модель лежащая под РСУБД. Она ни какого отношения к ООП не имеет. Более того. В ней даже терминов "объект" или "класс" нет.
C>В ней есть термин "кортеж". Классы банально преобразуется в кортежи, а дальше всё просто.

Классы не преобразуются в кортежи никак. У классов есть:
1. Названия.
2. Иерархия наследования.
3. Полиморфизм.
4. Инкапсуляция.

C>>>Другое дело, что реализации OODB могут отступать от строгой реляционной модели, например, с помощью оптимизации путей доступа к данным. Но то же самое могут делать и RDB.
VD>>ООБД не могут пользоваться реляционной алгеброй хотя бы потому, что в итоге получится РСУБД .
C>Так и получается.

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

VD>>И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки.
C>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.

Гы. Хранение в блобах — это не СУБД. А если используется реляционный движок, то это опять таки не ООБД, а надстройка.
Да и как иначе? Ведь много раз сказано было — ООП не был рассчитан на хранение данных в БД. Нет в нем соответствующих концепций. Концепции ООП отлично работают для классов в памяти, но никак для данных в БД. Более того ООП и средств обработки данных не предоставляет. Нельзя же считать императивные циклы таковыми?

Здравствуйте, Cyberax, Вы писали:

C>Что в ORMах ты собираешься описывать теоретически? Язык запросов в той же Hibernate является реляционно полным, это несложо доказать формально.

К сожалению нет NH не умеет делать join on X, где X задаешь ты сам. В некоторых случаях это не позволяет сделать нужные запросы.

Например есть две сущности Человек и Документ, одному человеку могут соответствовать несколько документов (удостоверяющих личность). Нужен список всех людей с их паспортами, если паспорта нет — null.
Хотелось бы что-то типа:

select ч.ФИО, д.Text from Человек ч left join Документ д on (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт).

Я так и не смог решить задачу с помощью HQL Есть идеи?

Здравствуйте, VladD2, Вы писали:

VD>Классы не преобразуются в кортежи никак. У классов есть:
VD>1. Названия.
У элементов кортежей в реляционной алгебре (см. операция RENAME) они тоже есть. Далее просто вводим название класса как alias для определённого набора названий кортежей.

VD>2. Иерархия наследования.
Отображается на кортежи (дискриминатором, join-таблицами).

VD>3. Полиморфизм.
Методы мы исключаем из рассмотрения.

VD>4. Инкапсуляция.
Аналогично, это требование элементарно удовлетворяется, если ORM имеет тот же доступ, что и члены самого класса.

C>>Так и получается.
VD>Тогда это не ООБЩ, а БД со встроенным ОРМ. Думаю, не надо объяснять, что получить производительности чистой РСУБД при таком подходе не легче (читай невозможно) чем при подходе с отдельными ОРМ и СУБД?
Тут вопросы не в теории, а в практике. L2-кэш в ORMах сейчас повторяет внутренние кэши в БД, да ещё руками приходится следить за его когерентностью. Имело бы смысл его интегрировать в саму БД, например. Ну и так далее...

C>>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.
VD>Гы. Хранение в блобах — это не СУБД.
Нет, это СУБД, просто не реляционная.

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

Если хочешь почитать теоретически выкладки о том, что я говорю, то почитай "Foundation for Object Relational Databases: The Third Manifesto" (http://www.acm.org/sigmod/record/issues/9503/manifesto.ps ). Которую написал никто иной, как Кристофер Дэйт.

Здравствуйте, Ziaw, Вы писали:

Z>

Z>select ч.ФИО, д.Text from Человек ч left join Документ д on (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт).
Z>

Z>Я так и не смог решить задачу с помощью HQL Есть идеи?
Есть:

select ч.ФИО, д.Text from Человек ч left join Документ д with (д.ЧеловекИд=ч.Ид and д.ТипДокумента = ТипДокумента.Паспорт)

Это если смотреть на грамматику HQL в Hibernate 3.2.