Здравствуйте, Ziaw, Вы писали:
C>>Это если смотреть на грамматику HQL в Hibernate 3.2. Z>Только я говорил про NHibernate, он не понимает with по крайней мере когда я проверял последний раз.
Ну так нефиг пользоваться китайскими подделками
Можно тогда ещё вроде так переписать:
select ч.ФИО, д.Text from Человек ч left join Документ д on д.Человек=ч
where
(д is null) or (д.ТипДокумента = ТипДокумента.Паспорт)
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
C>select ч.ФИО, д.Text from Человек ч left join Документ д on д.Человек=ч
C>where
C>(д is null) or (д.ТипДокумента = ТипДокумента.Паспорт)
C>
on
коллекции Документы у человека нет. С джойнами не все так здорово в HQL. Можно перевернуть в Документ д right join д.Человек ч, но остается проблема джойнов в графе не являющимся деревом. Я писал уже на эту тему в этой ветке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>
Re[20]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, VladD2, Вы писали:
VD>Тогда спор снова ни о чем, так как ты используешь не сам Кибернэйт, а его подмножество во многом пересекающееся с LINQ-ом (окромя того, что Кибернэйт не поддерживает интегрированных в язык, типизированных запросов).
Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) — это способ представлять БД как набор объектов.
VD>Суть же Кибернэйта несколько шире, как я понимаю. Вот цитата из описания Кибернэйта в Википедии: VD>http://ru.wikipedia.org/wiki/Hibernate_(библиотека) VD>Основные возможности VD>Явный упор на persistence, а не на mapping. Не правда ли?
Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а.
C>>Ну и представление ассоциаций в виде коллекций. VD>Это и LINQ2SQL с успехом делает.
Это и SQL при желании умеет. Но я имел в виду другое.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, VladD2, Вы писали:
C>>Нельзя. C>>Пожалуйста. VD>Вы батенька определитесь все же...
Не задавайте глупых вопросов!
C>>Собственно, практически ничем. Кроме того, что элементы кортежей являются типизированным и структурированными. VD>Э... Почти все известные мне SQL-СБУД хранят данные типизированно. Все эти varchar(max)/varchar2, int и т.е. — это, что по-твоему, не типы?
Они не являются структурированными.
VD>Структурированность в РБД — это реляционные отношения и нормализация данных. Так что она тоже есть, но выглядит по другому. Как правильно заметил Ваня реляция позволяет описать отношения данных, а конкретные иерархии строить для конкретных задач.
Вот эта структурированность и теряется. В результате запроса мы получаем кортежи неструктурированных данных. ORM позволяет их объединять в структуры.
VD>Может быть речь о наличии вложенных структур? Скажем Оракл позволяет делать вложенные структуры данных в столбцах. Но ты же его не называешь ООБД? Почему?
Это уже скорее элементы ООБД. В Оракле так вообще ещё и объектные таблицы есть.
C>>А типизированный и структурированый элемент — это и есть объект. VD>Это, извините, батенька чушь несусветная. В классическом процедурном Паскале были записи. В классическом фунциональном ML-е записи и кортежи. Все эти типы структурированы и статически типизированы, но они не объекты и даже не классы! Это просто комплексные типы данных.
Если к записям в Паскале добавить полиморфизм — то это уже можно и считать объектами (см. "Оберон" ). Правда вырожденными, без поведения.
VD>Причем кортежи еще и имен не имеют. Кортежи вообще 1 в 1 повторяют описание строк таблиц БД (да и по сути родились из единой теории).
Ну вообще-то не 1-в-1. В реляционной алгебре есть операция RENAME.
C>>Да. VD>Если ты со мной согласен, то лично я делаю вывод, что ты целиком на нашей стороне, просто путаешь терминологию. Но тогда я не пойму что ты нашел в этом Кибернейте?
То что он мне позволяет это делать с минимальными затратами.
VD>А в чем разница то? Хоть убей не вижу из твоих рассуждений. Ведь если мы пользуемся только POD-типами (структурами и/иди кортежами), то разницы нет никакой. Ну, разве что умозрительная.
Ну да. Примерно так.
VD>А вот если мы начинаем по полной программе ООП впихивать (с его полиморфизмом и инкапсуляцией), то как раз и нарываемся на то, что ООП не содержит концепций позволяющих эффективно обрабатывать данные и принуждает к использованию неэффективного навигационного метода работы с данными.
Полиморфизм в RDB тоже можно выразить.
А вот навигационный принцип — это как раз то, что отличает OODB от RDB. В чистой RDB его нет (в реальных RDB он часто есть как оптимизация), в OODB он возможен как один из вариантов.
Sapienti sat!
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, ., Вы писали: .>И правильно, остальное чисто инженерная нашлёпка для удобства использования, не несущая теоретического смысла.
S>>Затем мы увидим, что в реляционной алгебре есть несколько типов джойнов, но практически ни один из них не соответствует напрямую типам джойнов в SQL. S>>Оказывается, что большинству операторов РА в SQL нет прямых аналогов. А операторы, знакомые нам по SQL, в РА работают несколько по другому. .>А подробнее? Что не так? Всё вроде есть, даже агрегатные ф-ции.
Здравствуйте, приехали.
1. В РА нет значения unknown для булевых предикатов
2. В РА проекция всегда требует distinct, что не применяется в SQL по причинам производительности
3. Операции над множествами в РА построены на именах атрибутов, в SQL — на их позициях
4. Что у нас является SQL-аналогом операции деления в РА?
.>Эээ... почему не является?
Потому, что в SQL нет, в отличие от РА, ограничения на уникальность строк.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>Ну давай смотреть. В Вики перечислены следующие свойства реляционной алгебры: C>1) Проекция, выборка, фильтрование, переименование — всё есть в прямом виде. C>2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть.
Да? И где в SQL натуральный джойн? Где семи-джойн? Где деление? Где антиджойн?
C>В итоге, SQL прекрасно представляет реляционную алгебру.
Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>В ней есть термин "кортеж". Классы банально преобразуется в кортежи, а дальше всё просто.
Это чудовищная ересь. Читать определение класса и ООП до просветления.
VD>>И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки. C>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали: VD>>3. Полиморфизм. C>Методы мы исключаем из рассмотрения.
Исключением существенных свойств ничего хорошего ты не получишь.
На всякий случай напомню, что центральная идея ООП — это инкапсуляция поведения. Структура объекту нужна только для обеспечения поведения, заявленного контрактом. Она непрозрачна; два разных объекта с одним контрактом имеют полное право иметь различную внутреннюю структуру.
Это полная противоположность РА, в которой всё обязано быть открыто. В классическом ООП вообще не имеет смысла говорить об "именах атрибутов класса", потому что они исключительно локальны. В РА не имеет смысл говорить о "поведении" кортежей, потому что всё возможное "поведение" описано операторами РА.
В ООП центральным понятием является идентичность объекта, благодаря которому мы можем иметь два различимых объекта в одинаковых состояниях. В РА кортежи полностью описываются своим состоянием и неразличимы.
Неопытному взгляду эти вещи кажутся несущественными — чего там, добавим во все отоношения колонку "ID", и получим идентичность. Но это плохая абстракция. Дело в том, что РА замкнута относительно своих операторов; что бы ты ни делал с отношениями, ты в результате получаешь новое отношение. Достигается этот замечательный эффект именно благодаря прозрачности данных. Но если ты попробуешь применять операторы РА к "отношениям с ID", ты будешь получать непонятно что. Этим результатам нет аналога в ООП. У них нет идентичности, инкапсуляции и полиморфизма.
Попытка построить непротиворечивую алгебру, скрестив РА с ООП, была предпринята в 1993 году. Сейчас, с учетом накопленного опыта, можно смело считать эту попытку проваленной. Оказалось, что даже если отвлечься от поведения (что, как я уже сказал, фактически эквивалентно отказу от ООП), оставив только идентичность и наследование реализации, то получившаяся математика не допускает эффективной реализации. Ну и мозг программиста успешно взрывается из-за того, что появляется слишком много вторичных типов данных. Простейшие вопросы, например эквивалентность отношения из (Name, Age) и отношения (User[Name, Age]), оказываются нетривиальными.
Вот такая вот примерно идеология. Поэтому говорить о том, что "классы банально отображаются на кортежи" можно только от поверхностности, граничащей с некомпетентностью.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали: C>А типизированный и структурированый элемент — это и есть объект.
Щас прям. Это ты где взял, неужто в хелпе про Хибернейт?
Типизированный и структурированный элемент — это record, он value-type в отличие от объекта, который обязан быть reference-типом. Потому, что иначе у него не будет идентичности.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, VladD2, Вы писали:
VD>И вообще. На свете сокрее всего вообще нет ООБД. Например, Каше базируется на идеологии хранения данных в разреженных массивах. ООП в Каше наворачивается поверх движка на базе разреженных массиво. Это тоже самое что ОРМ. Другие ООБД используют реляционные движки. А вот СУБД с движком на основе ООП я почему-то не видел. Плохо смотрел?
Влад, уже несколько лет тут время от времени всплывает Gemstone/S.
Здравствуйте, Sinclair, Вы писали:
C>>2) Объединения: натуральный джойн, тэта-джойн, outer left/right, inner join — всё тоже есть. S>Да? И где в SQL натуральный джойн? Где семи-джойн? Где деление? Где антиджойн?
SELECT * FROM employee NATURAL JOIN department
Semi-join:
select *
from customer cust
where exists (
select *
from Sales sl
where sl.cust_id = cust.cust_id)
Аналогично с делением и анти-джойном.
C>>В итоге, SQL прекрасно представляет реляционную алгебру. S> S>Ее можно эмулировать на SQL без особых проблем. Тем не менее, SQL достаточно сильно отличается от "классической" РА, и именно потому, что "инженерные" соображения оказались важнее, чем 100% соответствие.
Он очень к ней близок.
Sapienti sat!
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Sinclair, Вы писали:
C>>А типизированный и структурированый элемент — это и есть объект. S>Щас прям. Это ты где взял, неужто в хелпе про Хибернейт? S>Типизированный и структурированный элемент — это record, он value-type в отличие от объекта, который обязан быть reference-типом. Потому, что иначе у него не будет идентичности.
Да, идентичность забыл. Но она тоже обеспечивается с помощью ORM, так что тут тоже не важно.
Sapienti sat!
Re[30]: Взаимодействие с Базой Данных из C# по схеме MS
C>Аналогично с делением и анти-джойном.
Я же сказал — сконструировать на SQL реляционные операторы можно. Но это не означает, что "SQL построен на RA". Я вот могу деление и на XPath изобразить, и что, будем говорить что XPath построен на РА?
C>Он очень к ней близок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
C>>SELECT * FROM employee NATURAL JOIN department
C>>
S>Да? Это из ANSI? Это хоть где-нибудь работает реально?
В PostgreSQL работает: http://www.postgresql.org/docs/8.0/interactive/queries-table-expressions.html
В MSSQL тоже, как и в Oracle.
S>Я же сказал — сконструировать на SQL реляционные операторы можно. Но это не означает, что "SQL построен на RA". Я вот могу деление и на XPath изобразить, и что, будем говорить что XPath построен на РА?
На XPath не изобразить остальные операции, AFAIK. Кстати, в самой РА достаточно только cross-join'а, всё остальное через него выражается (это если я не забываю что-то).
Sapienti sat!
Re[21]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
VD>>Тогда спор снова ни о чем, так как ты используешь не сам Кибернэйт, а его подмножество во многом пересекающееся с LINQ-ом (окромя того, что Кибернэйт не поддерживает интегрированных в язык, типизированных запросов). C>Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) —
Тогда уж "Гибирнейт". Но это уже детали.
C>это способ представлять БД как набор объектов.
Это-то и плохо. В прочем ты слишком вольно трактуешь цели Кибернейта. Меж тем они четко прописаны на сайте проекта.
VD>>Суть же Кибернэйта несколько шире, как я понимаю. Вот цитата из описания Кибернэйта в Википедии: VD>>http://ru.wikipedia.org/wiki/Hibernate_(библиотека) VD>>Основные возможности VD>>Явный упор на persistence, а не на mapping. Не правда ли? C>Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а.
Скорее проблемы тут у тебя, так как ты просто слишком вольно интерпретируешь информацию. На сайте Кибернейта написано тоже самое, что и в Вики. Странно, что ты до использования не почитал этот сайт .
C>>>Ну и представление ассоциаций в виде коллекций. VD>>Это и LINQ2SQL с успехом делает. C>Это и SQL при желании умеет. Но я имел в виду другое.
SQL? В нем даже понятия "коллекции" нет. О чем ты?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, VladD2, Вы писали:
C>>Интегрированные в язык запросы — это nice to have. Основная заслуга Hibernate (произносится "Хайбернейт", кстати) — VD>Тогда уж "Гибирнейт". Но это уже детали.
Ну не нравится мне коверканье английских слов
C>>Это проблемы конкретной статьи. Просто результатом нормального mapping'а графа объектов на реляционную базу данных будет являться удобный способ для persistance'а. VD>Скорее проблемы тут у тебя, так как ты просто слишком вольно интерпретируешь информацию. На сайте Кибернейта написано тоже самое, что и в Вики. Странно, что ты до использования не почитал этот сайт .
Спасибо, оказывается, что я все эти использовал Hibernate не для того, что нужно.
VD>>>Это и LINQ2SQL с успехом делает. C>>Это и SQL при желании умеет. Но я имел в виду другое. VD>SQL? В нем даже понятия "коллекции" нет. О чем ты?
Я же сказал — "при желании".
Sapienti sat!
Re[17]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
VD>>1. Названия. C>У элементов кортежей в реляционной алгебре (см. операция RENAME) они тоже есть. Далее просто вводим название класса как alias для определённого набора названий кортежей.
Ладно. Это и правда мелочь.
VD>>2. Иерархия наследования. C>Отображается на кортежи (дискриминатором, join-таблицами).
Наследование иерархично, соединения таблиц могут образовывать графы любой сложности. Именно об этом и говорил Ваня. Если тебе по логике юзкеса нужно дерево, то ты строишь его. Для другого юзкеса строишь другую иерархию...
VD>>3. Полиморфизм. C>Методы мы исключаем из рассмотрения.
Нет. Не исключаем. Или исключаем все и тогда остается только реляционная БД.
VD>>4. Инкапсуляция. C>Аналогично, это требование элементарно удовлетворяется, если ORM имеет тот же доступ, что и члены самого класса.
Ну, и на фиг нам тогда вообще нужна какая-то там объектность, если мы все что было в ООП выкинули?
Получается эдакий хреновенький недо-линк. Такой, медленный, нетипизированный и с большим количеством гемороя вокруг него.
C>>>Так и получается. VD>>Тогда это не ООБД, а БД со встроенным ОРМ. Думаю, не надо объяснять, что получить производительности чистой РСУБД при таком подходе не легче (читай невозможно) чем при подходе с отдельными ОРМ и СУБД? C>Тут вопросы не в теории, а в практике. L2-кэш в ORMах сейчас повторяет внутренние кэши в БД, да ещё руками приходится следить за его когерентностью. Имело бы смысл его интегрировать в саму БД, например. Ну и так далее...
Имело бы смысл отказаться от бредовых идей и заняться чем-то по перспективнее. А пытаться намертво склеить ОРМ с РСБУД получив в итоге
все проблемы ОРМ-ов и отсутствие возможности обратиться к БД напрямую, занятие схожее с мазохизмом.
C>>>Есть чистые OODB, я работал с DB4o — оно может хранить объекты напрямую в виде аналога сериализованного графа. Хотя для скорости всё равно приходится объекты хранить в виде таблиц. VD>>Гы. Хранение в блобах — это не СУБД. C>Нет, это СУБД, просто не реляционная.
ОК. Договорились! Такая СУБД была создана лет 50 назад. Называется — файл. Тебе ее должно хватить. Что тогда спорить о терминах? Мы же ведь просто под термином "СУБД" понимаем разные вещи.
VD>>А если используется реляционный движок, то это опять таки не ООБД, а надстройка. VD>>Да и как иначе? Ведь много раз сказано было — ООП не был рассчитан на хранение данных в БД. Нет в нем соответствующих концепций. Концепции ООП отлично работают для классов в памяти, но никак для данных в БД. Более того ООП и средств обработки данных не предоставляет. Нельзя же считать императивные циклы таковыми? C>Кем сказано было?
Мной.
C>Если хочешь почитать теоретически выкладки о том, что я говорю, то почитай "Foundation for Object Relational Databases: The Third Manifesto" (http://www.acm.org/sigmod/record/issues/9503/manifesto.ps ). Которую написал никто иной, как Кристофер Дэйт.
Ё! Опять постскипт? У меня складывается ощущение, что некоторые люди делают все, чтобы их не читали. Мне просто влом искать то чем это дело можно конвернуть в читабельный формат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Sinclair, Вы писали:
S>Поэтому говорить о том, что "классы банально отображаются на кортежи" можно только от поверхностности, граничащей с некомпетентностью.
Тут, мне кажется, ноги растут от банального самовнушения. Мужик в общем-то стоит на одних позициях с нами. Только вот беда. Когда он занялся вопросом обработки данных в ООП-приложениях, то Линк-а еще не было. Он взял на вооружение то что попалось под руку — Кибирнейт — и переосмыслил его.
Он пропустил мимо ушей все идеологические предпосылки которые даются в первых абзацах первой страницы кибернейтовского сайта (где говорится о персистентности, ООП и другой прозрачностей). Далее он ограничил возможности Кибернэйта возможностями примитивного конвертера с поддержкой нетипизированных запросов и в итоге получил нечто очень похожее н Лник.
Спорить с ним бесполезно, так как мы говорим, о том как Кибернэйм позиционируют его авторы, а он о том виртуальном Кибернейте который был создан его воображением путем ограничения возможностей и перенацеливания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS