Про ORM

Оно нужно для абстракции -> высокоуровневого программирования. Когда можно слегка забить на скорость. Если критично к скорости, продукт дорабатываться не будет (хотел бы я увидеть такой продукт) --- однозначно не нужно.

Проблема отпадёт с приходом нормальных ООСУБД (не надстройки над РСУБД, а полностью объектных, типа CODB (CLIP Object DB)).

Нужно, чтобы было проще соблюдать принцип DRY.

ППКС, только нормальные ООСУБД уже давно пришли и во многих случаях оправданней СУБД с костылями, мешает лишь инертность.

>Нужно ORM, не нужно?

Вообще, при использовании ORM возникает такой зверь как Object-relational Impedance Mismatch. Дискуссии по этому поводу идут кажись с начала 90-х.

Так что наверно лучше использовать ОО базы данных.

Вопрос знатокам: реляционная модель имеет фундаментальное теоретическое основание в виде теории множеств, а что в фундаменте имеет объектная модель?

Мне даже на «глобальном и надёжном» пришлось на ORM переходить. Прямая работа с БД в общем случае - зло. Допустима только в редких частных случаях :)

> нормальные ООСУБД уже давно пришли

Куда они пришли и как их зовут?

Если применять ORM с умом, то получается вполне полезная штука. Особенно православно получается в связке со всякими автоматическими генераторами исходных кодов. Надо добавить новые данные в какой-нибудь объект - правищь метаописание, запускаешь генератор, получаешь SQL-и, новый объектный API для работы с БД в котором учтены нужные изменения. Остается только логику основной программы подправить. Исключительно удобно, мы пользуемся. Если язык статически-типизируемый то вообще классно.

Не все ORM'ы одинаково полезны. ORM должен быть достаточно универсальным. Что касается синтаксиса, в случае сложных запросов, всё становится ещё запутаннее, чем с SQL.

Но в простых случаях определённо ORM - добро.

>Надо добавить новые данные в какой-нибудь объект - правищь
>метаописание, запускаешь генератор, получаешь SQL-и,
>новый объектный API для работы с БД в котором учтены нужные изменения.

Как много теложвижений :D

Правильная ORM - это когда для создания объекта нужно только описать БД и поля:

class aviaport_conferences_post extends base_object_db
{
    function main_db_storage() { return config('main_bors_db'); }
    function main_table_storage() { return 'conferences_posts'; }

    function main_table_fields()
    {
        return array(
            'id',
            'topic_id',
            'source',
            'url_id',
            'is_moderated',
            'owner_id',
            'owner_name',
            'create_time',
            'modify_time',
            'is_deleted',
            'is_hidden',
        );
    }
...

В простейшем случае - всё. Потом надо, скажем, вытащить все постинги
за последние сутки:

$list = objects_array('conferences_posts', array('create_time>' => time()-86400));

И в шаблоне вывод:

<ul>
{foreach from=$list item="p"}
<li>{$p->titled_url()}</li>
{/foreach}
</ul>

:)

Да, естественно, объекты можно произвольно модифицировать:

$obj = object_load('conferences_post', 12345);
$obj->set_title('Новый заголовок', true);

система сама всё в конце работы сбросит в БД...

...

А метоописания, генераторы... Это не для ленивых. Я - ленив :D

>а что в фундаменте имеет объектная модель

там все точно так же. и алебра есть, и оптимизация, и все все все. другое дело, что одб много где не преподается.

>там все точно так же. и алебра есть,

А подробнее?

Теория множеств тоже много где не преподаётся, но это реальная математическая дисциплина. Какая математическая дисциплина (не костыли и надстройки, а именно самостоятельная дисциплина) соответсвует ОО?

а... ты об ОО, а не о ООДБ? не отвечу.

и тогда встречный вопрос: какая математическя дисциплина соответствует (не ОО)?

Далеко не все языки имеют развитую рефлексию чтобы реализовать такой подход. А если и имеют - она обычно оказывается медленнее чем прямой доступ к свойствам.

Я тоже генерирую код для работы с БД - быстро и удобно, 2-мя кнопками. Если говорить о .NET, то далеко не факт что ORM-решение будет медленнее чем стандартный подход. В качестве ОРМ использую собственноручно построенный велосипед. Надо будет опубликовать его под БСД.

я тебе могу дать 2 линка: http://uosis.mif.vu.lt/~arunas/ODB/doc/manifesto.zip и http://uosis.mif.vu.lt/~arunas/ODB/doc/konspektai.zip

первое - абстрактная вода с кучей референцов, вторая поконкретнее, но на литовском :)

А вообще, ООСУБД не нужны. Нужны реализации "Третьего манифеста".

Я имел в виду именно ООБД. Что представляют из себя реляционные БД я представляю по тем огрызкам теории множеств которые я знаю, а что такое ООБД я не представляю поэтому и спрашиваю.

все тоже самое, только оперируется не записями, а объектами. весь ужас ООДБ в том, что объекты имеют методы, а это значит, что этот весь аппарат не подчиняется логике первого порядка.

ну а это значит, что даже непротиворечивость достигается нелегкими путями: для каждого метода нужно доказать (автоматически), что он не противоречив. с этого песта включается libastral, который реализован на подабающем уровне только в единицах реализаций за бешанные бобы :/

> Проблема отпадёт с приходом нормальных ООСУБД

проблема отпадает с приходом кэширования запросов.

Если изначально дано: сервер РСУБД и в альтернативе только писать запросы вручную - конечно нужно. А так вон люди на смолтоке десятилетиями использовали свои, смолтоковские бд, где мапить в объекты ничего не нужно (сам немного пользовался Seaside\Squeak и Gemstone ). Получается тормознее и ущербнее чем РСУБД, зато как правило меньше проблем с масштабированием. Та же kirbybase и теперь strokedb в руби. Вообще document-oriented DB вроде couchdb или аналог от амазона - имхо для маленьких проектов один из лучших вариантов.

Вообще конечно смотря что за цель. Если веб-приложения строим то сейчас многие используют СУБД просто как тупое хранилище, и вся мощь того же постгреса нафиг не нужна ( по своему мааленькому опыту, на истинность не претендую )

> Вопрос знатокам: реляционная модель имеет фундаментальное теоретическое основание в виде теории множеств, а что в фундаменте имеет объектная модель?

http://compzed.narod.ru/teorfram.htm

Ы?

> и тогда встречный вопрос: какая математическя дисциплина соответствует (не ОО)?

http://lib.ru/CTOTOR/DEJKSTRA/

Ы?

> Что представляют из себя реляционные БД я представляю по тем огрызкам теории множеств которые я знаю, а что такое ООБД я не представляю поэтому и спрашиваю.

Элементы ООБД есть, например, в PostgreSQL -- это прозрачное "наследование таблиц". Возможность выборки всей иерархии связанных объектов за одно предложение (вообще в этом смысле ООБД -- это частный случай иерархических и сетевых БД с добавленным наследованием), поиск по древовидному шаблону (object tree pattern matching) наподобие того, как это сделано в Prolog, XPath и CSS-селекторах.

А вообще, все это пока теория и кусочки практики. Законченную ООБД я еще ни разу не видел, хотя помню, в 2002 одна такая была на слуху. Но с тех пор я уже даже имя ее забыл...

> поиск по древовидному шаблону (object tree pattern matching) наподобие того, как это сделано в Prolog, XPath и CSS-селекторах.

Кста, PM вообще очень популярен в современных функциональных языках (чуть ли не в фундаменте заложен). Так что, ряд можно продолжить...

> все тоже самое, только оперируется не записями, а объектами. весь ужас ООДБ в том, что объекты имеют методы, а это значит, что этот весь аппарат не подчиняется логике первого порядка.

Кстати, и это тоже, да. Инкапсуляция поведения в записи, я забыл.

а че Ы?

вопрос-то и без вашества исчерпали уже

> вопрос-то и без вашества исчерпали уже

А рази ссылки не по теме?

> ну а это значит, что даже непротиворечивость достигается нелегкими путями: для каждого метода нужно доказать (автоматически), что он не противоречив. с этого песта включается libastral, который реализован на подабающем уровне только в единицах реализаций за бешанные бобы :/

По отзывам тех, кто работал с Objectivity даже бешенные бабки не помогли сему поделию и отсюда возникают большие сомнения в принципильной возможности непротиворечивой реализации оного чуда. Посему реляционные СУБД жить будут ещё долго после того как объектные умрут. IMHO, естественно.

>> Вопрос знатокам: реляционная модель имеет фундаментальное теоретическое основание в виде теории множеств, а что в фундаменте имеет объектная модель?

>http://compzed.narod.ru/teorfram.htm

Какая-то философия. А где математика?

Naomi, вам надо побрить бороду и удалить ФГМ.

> Элементы ООБД есть, например, в PostgreSQL

Я говорю не про элементы (aka нашлёпки новых типов данных над реляционной моделью). Я говорю про принципиальное противоставление реляционных БД объектноориентированным. До реляционной модели Кода были популярны иерархические БД и они умерли именно потому, что реляционная модель была непротиворечива в силу теоретического фундамента в отличии от. То есть не потому что иерархическая модель никуда не годилась, а потому что реляционная модель была много лучше. Чем лучше ОО модель мне абсолютно не понятно.

> Чем лучше ОО модель мне абсолютно не понятно.

Тем, что, в отличие от Коддовской, позволяет гораздо проще отображать объекты, которыми манипулируют программы, на объекты БД. Но после "Третьего манифеста" это уже не совсем так.

Математическую теорию пожалуйста в студию. Слишком обще.

> Математическую теорию пожалуйста в студию.

Я разве сказал, что она есть? Почитай http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manifesto...., хотя для любителей математики там только Introduction.

> Слишком обще.

Подумай, как отобразить дерево на таблицу, потом - дерево с полиморфными узлами, потом - что домен значения в классической РМ - атомарный тип. Поймешь, что такое impedance mismatch.

> Я говорю про принципиальное противоставление реляционных БД объектноориентированным.

А принципиального протвиоставления и нет. Ибо каждая таблица -- это примитивный фрейм, каждое поле -- примитивный слот и т.д. Речь идет об улучшениях.

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

Отнюдь нет. Многие современные языки программирования очень тяжело верифицируются, а то и вообще неверифицируемы. Это не мешает вполне успешно их использовать.

Победа технологии отнюдь не определяется качеством фундаментальной абстракции. Сейчас навалом разработчиков БД, которые с трудом вспомнят, что такое НФ, и для чего они нужны. Ибо на практике грамотная денормализация дает намного меньше геморроя, чем отсутствие таковой.

> То есть не потому что иерархическая модель никуда не годилась, а потому что реляционная модель была много лучше.

Она не лучше, она банально быстрее. Точнее, позволяет создавать быстродействующие СУБД.

> Чем лучше ОО модель мне абсолютно не понятно.

Уровнем абстракции. Грубо говоря, SQL местами слишком низкоуровневый, о чем свидетельствует монстроидальность SQL-запросов при вытягивании иерархий и поиске по ним. А местами им вообще без императивной надстройки и не воспользуешься. Потому разработчики часто и отказываются от нормальных форм -- по науке получается уж очень накладно.

Вы IMHO сбиваетесь на частности. Программы действительно могут оперирировать тем, что называется объекты (aka структура данных + способы работы с ними), но только эти программы и знают как с этими объектами обращаться. Пихать новые типы в БД конечно можно, но это ничего принципиально нового от типа integer в себе не несёт. Да, для каких-то задач получится написать на две строчки кода меньше, но принципиально от работы с данными как работы с множествами уйти не удастся. По ссылке, как я понял, в основном идёт именно описание данных и нигде не отрицается наличие множеств этих данных и операций с ними - то есть реляционная модель поверх каких-то типов данных - ничего особенного, только слишком всё усложненно.

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

По-моему мы с вами говорим примерно одно и тоже.

> Вы IMHO сбиваетесь на частности.

Нет. Само существование ORM'ов как бэ говорит, что я прав :)

> Пихать новые типы в БД конечно можно, но это ничего принципиально нового от типа integer в себе не несёт.

Ч0рт... я вечно забываю сказать о "Третьем манифесте" %)

> Иерархические БД это действительно принципиально другие БД, которые не ложатся на реляционную модель. Такие БД были до реляционных, существуют и сейчас, но для подавляющего большинства случаев они весьма не шибко быстрые

Ну, <историк моде> иерархические БД были в основном вытеснены сетевыми, а потом сетевые вытеснены реляционными, причем одним из ранних аргументов против РСУБД была как раз их скорость (современные РСУБД - это плод десятилетий разработки и закона Мура) </историк моде>.

> Иерархические хранилища могут эмулироваться над реляционными.

И наоборот.

> По-моему мы с вами говорим примерно одно и тоже.

Мы расходимся в направлении. Вы считаете, что реляционные модели нужно надстраивать над сложными типами данных, а я считаю, что наоборот, сложные типы данных нужно строить на основе реляционных.

В этом смысле реляционные СУБД "уйдут под капот", как в современных условиях ушел ассемблер, уступив место более сложным языкам.

> одним из ранних аргументов против РСУБД была как раз их скорость (современные РСУБД - это плод десятилетий разработки и закона Мура)

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

>> Иерархические хранилища могут эмулироваться над реляционными.

> И наоборот.

Да. А медведя можно научить ездить на велосипеде.

>> одним из ранних аргументов против РСУБД была как раз их скорость (современные РСУБД - это плод десятилетий разработки и закона Мура)

> Откуда дровишки?

Из старых бумажных книг. Кажется, Дейт, и работы по System R.

>>> Иерархические хранилища могут эмулироваться над реляционными.

>> И наоборот.

>Да. А медведя можно научить ездить на велосипеде.

В общем, да. Только медведи не выполняют при этом никакой полезной работы.

> В общем, да. Только медведи не выполняют при этом никакой полезной работы.

Кстати +1. Это к вопросу об осмысленности упрощения "среднестатистическому программисту" жизни в ущерб чистоте подхода.

> Ну, <историк моде> иерархические БД были в основном вытеснены сетевыми, а потом сетевые вытеснены реляционными, причем одним из ранних аргументов против РСУБД была как раз их скорость (современные РСУБД - это плод десятилетий разработки и закона Мура) </историк моде>.

Здесь я действительно не правильно сформулировал. Сорость работы для простых операций типа вставки действительно у РСУБД медленнее чем работа с той же файловой системой, но даже для не сильно нетривиального поиска и при масштабировании всего этого хозяйства данный факт становится уже не так очевиднен. То, что Мур сильно РСУБД помог, абсолютно огласен, как и с тем, что с небольшим объёмом данных просто файловой системы более чем достаточно.

> Куда они пришли и как их зовут?

В наш мир :) На вики можно почитать, я с db4o чуть-чуть имел дело, мне этого хватило, РСУБД при прочих равных я предпочту, только если будет критична скорость.

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

>Вопрос знатокам:

отвечает Александр Друзь

> реляционная модель имеет фундаментальное теоретическое основание в виде теории множеств, а что в фундаменте имеет объектная модель?

Метаобъектный протокол как универсальная модель класса объекта, унифицированная модель данных, аспектно-ориентированное программирование как реализация этой модели (MOP можно реализовать через AOP), вызов методов как транзакций.

При более гибкой объектной системе (в стиле ближе к CLOS или Smalltalk, а не C++/Java) можно придумать более эффективную поддержку AOP приложения (поддержка AOP системы-приложения объектной моделью БД).

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

В подтверждение того же принципа DRY. Только должно быть полностью завершенным, генерировать и схему данных тоже. А то наткнулся вот в одном проекте на глюки Hibernate: есть поле, в новой версии объекта не используется, в БД вообще стоит null, схему данных в Hibernate вовремя не обновили -- Hibernate не может сериализовать объект и выбрасывает exception. Пришлось для начала руками залезть в базу, поставить 0 вместо null, потом уже и схему поправить.

> весь ужас ООДБ в том, что объекты имеют методы,

и наследуются, вместе с данными.

> Какая математическая дисциплина (не костыли и надстройки, а именно самостоятельная дисциплина) соответсвует ОО?

алгебра, кольца и свойства групп? топология?

>> весь ужас ООДБ в том, что объекты имеют методы,

> и наследуются, вместе с данными.

И хранятся вместе с данными? 8)