Comments 59
цель не достигнута имхо
За статью спасибо, очень интересно взглянуть на проблему ORM с точки зрения ее отсутствия :)
Однако ИМХО, объектные БД еще недостаточно зрелые, и в серьезный продакшн их пускать рано. Для примера можно взять хотя бы присутствие такого параметра, как «глубина активации ссылок» — хотя, по идее, этим должна заниматься БД, а не программист, предсказывая, как далеко по ссылкам ему придется ходить.
Однако ИМХО, объектные БД еще недостаточно зрелые, и в серьезный продакшн их пускать рано. Для примера можно взять хотя бы присутствие такого параметра, как «глубина активации ссылок» — хотя, по идее, этим должна заниматься БД, а не программист, предсказывая, как далеко по ссылкам ему придется ходить.
Как раз для решения этой проблемы в последних версиях db4o есть Transparent Activation. Данная тема в введение не влезла :)
Очень интересно, и статья понравилась, db4o надо обязательно попробовать…
Мне одному напрашивается решение проблемы «глубины активации» и т.д. с помощью атрибутов полей классов? :)
Мне одному напрашивается решение проблемы «глубины активации» и т.д. с помощью атрибутов полей классов? :)
Думаю, что это неподходящее решение. Дело в том, что один и тот же класс может быть использован в различным ситуациях, когда объем графа(назовем так метрику, пропорциональную среднему диаметру графа, т.е. суммарной длине ссылок среднего «маршрута») может меняться достаточно сильно.
Не перекомпилировать же приложение.
Не перекомпилировать же приложение.
Вообще то объектные базы давно используются в самых разных местах. db4o не самый удачный пример и далеко не самая зрелая технология.
Из коммерческих мне приходилось работать с Matisse, давно доступна на рынке, на ней реализован был Craigslist, атомные станции управляются системами с Matisse во Франции, Los Alamos National Laboratory (сами знаете чем они там занимаются), ЦРУ и прочие ФБР.
Объектные базы вообще и Matisse в частности используются для работы с очень сложными моделями, в которых из-за большого количества типов объектов и связей использовать реляционные базы невыгодно.
Последний раз я работал с Matisse 6 лет назад и тогда это было очень круто — рисуешь все в Rational Rose в UML и собственно это и была схема базы. Из розы одним кликом в Matisse.
Есть еще разумеется Caché, тоже уже очень давно на рынке.
Из коммерческих мне приходилось работать с Matisse, давно доступна на рынке, на ней реализован был Craigslist, атомные станции управляются системами с Matisse во Франции, Los Alamos National Laboratory (сами знаете чем они там занимаются), ЦРУ и прочие ФБР.
Объектные базы вообще и Matisse в частности используются для работы с очень сложными моделями, в которых из-за большого количества типов объектов и связей использовать реляционные базы невыгодно.
Последний раз я работал с Matisse 6 лет назад и тогда это было очень круто — рисуешь все в Rational Rose в UML и собственно это и была схема базы. Из розы одним кликом в Matisse.
Есть еще разумеется Caché, тоже уже очень давно на рынке.
Судя по документации (сам с ними не работал), обе упомянутые СУБД действительно очень мощные. Помимо поддержки объектного интерфейса к ним можно делать запросы на расширенном SQL. Последнего в db4o нет. Однако, что касается работы с БД на уровне объектов (без ORM) у db4o есть большие преимущества. Matisse и Caché требует для работы генерировать прокси-классы для хранимых классов и работать с БД через них. В db4o этого делать не надо, интерфейс более естественный — мы работаем с собственными классами.
Для более подробной информации вот ссылки на доки (.NET): Matisse, Caché.
Для более подробной информации вот ссылки на доки (.NET): Matisse, Caché.
Не нашел ответов в статье на следующие очевидные вопросы.
Возможно ли сохранить граф объектов (с циклами)?
Как разрешается identity проблема, то есть если два объекта ссылаются на третий, то при сохранении первого, а затем второго будет ли это связь учтена в DB?
Как на счет скорости, какие ограничения на размер DB?
Возможно ли сохранить граф объектов (с циклами)?
Как разрешается identity проблема, то есть если два объекта ссылаются на третий, то при сохранении первого, а затем второго будет ли это связь учтена в DB?
Как на счет скорости, какие ограничения на размер DB?
1) Можно.
2) Да, связь учтена будет. Identity разрешается в точности, как в самом ЯП (по ссылке).
3) Информации по вопросам производительности и масштабируемости очень мало. Собственного исследования на данной момент также не проводил. Все, что могу сейчас дать, это ссылка на benchmark на сайте db4o. Сам объективность приведенных данных не проверял и не знаком с методикой тестирования.
2) Да, связь учтена будет. Identity разрешается в точности, как в самом ЯП (по ссылке).
3) Информации по вопросам производительности и масштабируемости очень мало. Собственного исследования на данной момент также не проводил. Все, что могу сейчас дать, это ссылка на benchmark на сайте db4o. Сам объективность приведенных данных не проверял и не знаком с методикой тестирования.
Есть что-нибудь подобное для ruby?
Некоторое подобие — Maglev. Они объектную БД для Руби завернули в прикольную обертку — там по сути нет явного процесса сохранения, все работает прозрачно для программиста. Вообщем, смотрите скринкаст :)
Maglev — это адаптированный GemStone/S, доступный для Smalltalk'a с 1992 года. Он упоминается еще в книге Фаулера, посвященной рефакторингу. Кстати на идею создания Maglev авторов натолкнула мысль отсутствия вменяемой VM для ruby и то, что Smalltalk почти полностью покрывает сам Ruby.
Да, вы правы. И?
Что Вы думаете о CouchDB?
P.S. Я знаю, что это не объектно-, а документ-ориентированная БД, но правильно ли я понимаю, что документ-ориентированная БД является расширением ООСУБД?
P.S. Я знаю, что это не объектно-, а документ-ориентированная БД, но правильно ли я понимаю, что документ-ориентированная БД является расширением ООСУБД?
Не знаю, что скажет автор, но боюсь, что понимаете неправильно. CouchDB — это ближе к column-oriented и key-value-pair хранилищам. При этом, однако, CouchDB не является ни тем ни другим.
Первый раз слышу о CouchDB. Обязательно посмотрю, что это! Спасибо за наводку! :)
Могу предложить тогда «до кучи» еще SimpleDb и FeatherDb посмотреть и сравнить :)
и ещё на Persevere можете глянуть.
Сразу можно начинать читать с Comparison with CouchDB and Others, там как раз небольшой обзорчик похожих технологий.
Сразу можно начинать читать с Comparison with CouchDB and Others, там как раз небольшой обзорчик похожих технологий.
Спасибо за статью! Несколько лет работаю программистом и работа с базами данных, как и у всех наверное, ежедневное занятие. Но обьектные никогда в глаза не видел. Супер!
Вопрос только такой: как делаются миграции в таких базах? когда нужно менять структуру? т.е. я меняю описание класса когда уже данные есть?
Вопрос только такой: как делаются миграции в таких базах? когда нужно менять структуру? т.е. я меняю описание класса когда уже данные есть?
В случае удаления/добавления полей и классов проблем нет. Когда надо переименовать поле или класс, следует использовать API db4o приблизительно так:
Db4oFactory.Configure().ObjectClass(typeof(User)).Rename(«NewClassName»);
Db4oFactory.Configure().ObjectClass(typeof(User)).ObjectField(«Login»).Rename(«NewFieldName»);
Как ни странно, в Object Manager Enterprise визуальных средств для этого нет.
Db4oFactory.Configure().ObjectClass(typeof(User)).Rename(«NewClassName»);
Db4oFactory.Configure().ObjectClass(typeof(User)).ObjectField(«Login»).Rename(«NewFieldName»);
Как ни странно, в Object Manager Enterprise визуальных средств для этого нет.
Вот ещё ссылка по теме.
UFO just landed and posted this here
где самое главное — тесты производительности и масштабируемость?
Интересно, но технология еще не обкатана. Много деталей остаются неясными.
1. Есть ли возможность индексирования поиска по полям?
2. Кеш объектов и выборок.
3. Интеграция с фреймворками высокого уровня, напр. EMF
4. Система локов.
1. Есть ли возможность индексирования поиска по полям?
2. Кеш объектов и выборок.
3. Интеграция с фреймворками высокого уровня, напр. EMF
4. Система локов.
Мы для своей задачи тестили db4o и не возрадовались.
Я даже очень-очень-приочень хотел, чтобы мы возрадовались, но не судьба…
Возможно это пока.
=Конфиг=
Клиент-сервер. На сервере поднята служба, как в хелпе db4o. Работа с SQL`ем и OODB идут на одном сервере с одного и того же клиента.
=Результаты=
Sql-Server:
— 0.18 секунды 5000 записей, с наполнением объекта-списка
db4o:
— 0.3 секунды 5000 объектов (все имеющиеся)
— 5.5 секунд объект список состоящий из 5000 объектов
— 10 секунд рандомная загрузка 50 объектов
Я даже очень-очень-приочень хотел, чтобы мы возрадовались, но не судьба…
Возможно это пока.
=Конфиг=
Клиент-сервер. На сервере поднята служба, как в хелпе db4o. Работа с SQL`ем и OODB идут на одном сервере с одного и того же клиента.
=Результаты=
Sql-Server:
— 0.18 секунды 5000 записей, с наполнением объекта-списка
db4o:
— 0.3 секунды 5000 объектов (все имеющиеся)
— 5.5 секунд объект список состоящий из 5000 объектов
— 10 секунд рандомная загрузка 50 объектов
попробуйте Zope, я там такое делал еще 5 лет назад. Этой python фреймворк; используя внутреннюю БД, можно делать необходимые объекты.
UFO just landed and posted this here
Мгм, а зачем?
UFO just landed and posted this here
Как вариант пользуйтесь apc, memcache.
ООДБ — да, красиво, но…
Пока такие ООДБ проигрывают для PHP по соотношению Цена разработки/скорость работы.
Плюс, я, просто, не встречал на PHP серьезных разработок базирующихся на доменной архитектуре, где интересно хранить именно объекты. Поэтому возник вопрос, а зачем это надо? :)
ООДБ — да, красиво, но…
Пока такие ООДБ проигрывают для PHP по соотношению Цена разработки/скорость работы.
Плюс, я, просто, не встречал на PHP серьезных разработок базирующихся на доменной архитектуре, где интересно хранить именно объекты. Поэтому возник вопрос, а зачем это надо? :)
А в чем в данном случае отличие PHP от C#, что для шарпов это надо, а для пыха — нет?
Уровень абстракции и развитость платформы у Java, C# выше.
Это не плюс и не минус, просто это так есть.
К примеру, на PHP каждый второй, средней руки специалист пишет свой DB access layer или framework. На C#, Java — это редкое явление.
Это не плюс и не минус, просто это так есть.
К примеру, на PHP каждый второй, средней руки специалист пишет свой DB access layer или framework. На C#, Java — это редкое явление.
А что мешает взять хорошую реализацию.хорошего специалиста и подключать ее в качестве библиотеки? Жава настолько высоко развита, что у нее есть import, а у пыха — нет require_once?
А вообще, неправда ваша в данном случае. Тот же пропел под пых есть.
А вообще, неправда ваша в данном случае. Тот же пропел под пых есть.
Сколько не бери специалистов, пока не будет инструментария и библиотек соответствующего уровня — ничего не изменится.
Propel и NHibernate сильно разные вещи.
Вы просто попробуйте написать средний проект (от 100к строк) на C#, Java, PHP и поймете разницу.
PHP более низкоуровневый — именно этим он и удобен для большинства веб-сайтов
(больший контроль над всем, меньший оверхед и т.д.)
Propel и NHibernate сильно разные вещи.
Вы просто попробуйте написать средний проект (от 100к строк) на C#, Java, PHP и поймете разницу.
PHP более низкоуровневый — именно этим он и удобен для большинства веб-сайтов
(больший контроль над всем, меньший оверхед и т.д.)
«Сколько не бери специалистов, пока не будет инструментария и библиотек соответствующего уровня — ничего не изменится.»
Ну их писать-то кто-то должен? Вот написал я сайтик — почему бы не выложить его исходник на Google Code? Если он написан грамотно, то все использующиеся внутри классы/процедуры можно легко превратить в библиотеку, а сам сайтик — во фреймворк для создания сайтов такого типа. Немного документации — и вот уже готовая технология.
Где-то через месяц нужно будет писать сайт на PHP, у меня уже есть с прошлого года склонированный вплоть до названий классов каркас эмуляции сервлетов, а на нем — php-клон фреймворка Apache Turbine (версии 1). Конечно, всё это нужно доводить, и если таки придется писать на пыхе — доведу.
«Вы просто попробуйте написать средний проект (от 100к строк) на C#, Java, PHP и поймете разницу.»
Да я на каждой из этих технологий написал немало.
И на Жаве можно писать спокойненько вывод странички «вручную». Забабахал сервлет, и пиши в out что хочешь. Куда уж более низкоуровнево?
«больший контроль над всем»
и над чем же, интересно, контроль, над этим всем? Что там есть-то кроме HTML-кода, с чем может нативно работать PHP? Что такое может PHP-скрипт, чего не может сервлет + JDK?
«меньший оверхед»
ваще не к разработчику. проблемы провайдера.
а если покупать собсвтенный сервер для сайта — ну и на чем там экономить? На планке оперативки за две тысячи рублей?!
Ну их писать-то кто-то должен? Вот написал я сайтик — почему бы не выложить его исходник на Google Code? Если он написан грамотно, то все использующиеся внутри классы/процедуры можно легко превратить в библиотеку, а сам сайтик — во фреймворк для создания сайтов такого типа. Немного документации — и вот уже готовая технология.
Где-то через месяц нужно будет писать сайт на PHP, у меня уже есть с прошлого года склонированный вплоть до названий классов каркас эмуляции сервлетов, а на нем — php-клон фреймворка Apache Turbine (версии 1). Конечно, всё это нужно доводить, и если таки придется писать на пыхе — доведу.
«Вы просто попробуйте написать средний проект (от 100к строк) на C#, Java, PHP и поймете разницу.»
Да я на каждой из этих технологий написал немало.
И на Жаве можно писать спокойненько вывод странички «вручную». Забабахал сервлет, и пиши в out что хочешь. Куда уж более низкоуровнево?
«больший контроль над всем»
и над чем же, интересно, контроль, над этим всем? Что там есть-то кроме HTML-кода, с чем может нативно работать PHP? Что такое может PHP-скрипт, чего не может сервлет + JDK?
«меньший оверхед»
ваще не к разработчику. проблемы провайдера.
а если покупать собсвтенный сервер для сайта — ну и на чем там экономить? На планке оперативки за две тысячи рублей?!
Извините, но для меня это разговор с глухим, тем более, если вы говорите — писали много на всех 3х языках. Разницу должны понимать.
На Java никому в голову не придет писать raw-html в out. Просто потому что это неудобно и вне рамок технологии. Есть стандартные компоненты, фреймворки их и используют.
Вы видели html сгенерированный на ASP.NET? Это же жесть.
Тем не менее писать его достаточно просто, пока работаешь с компонентами. А вот спустится до уровня чистого html — проще застрелиться и писать действительно весь вывод в out. Но для .NETчика это мартышкин труд.
На PHP просто нет соответствующих библиотек такого качества, зато я четко контролирую что у меня будет в html (впрочем и выхода особого нет :) ). ez, ZF, CI, Doctrine достаточно сыроваты. Они писались в определенных условиях, под определенные нужды.
Поэтому даже средние специалисты часто пишут свое. Хорошие специалисты уже написали и пользуются своим.
P.S. если вы не в курсе, я пишу на PHP в основном.
Лет через 5ть мы, возможно, увидим прогресс. Вопрос какой ценой. За легкость разработки и лишние абстракции всегда надо платить и производительностью и деньгами.
На Java никому в голову не придет писать raw-html в out. Просто потому что это неудобно и вне рамок технологии. Есть стандартные компоненты, фреймворки их и используют.
Вы видели html сгенерированный на ASP.NET? Это же жесть.
Тем не менее писать его достаточно просто, пока работаешь с компонентами. А вот спустится до уровня чистого html — проще застрелиться и писать действительно весь вывод в out. Но для .NETчика это мартышкин труд.
На PHP просто нет соответствующих библиотек такого качества, зато я четко контролирую что у меня будет в html (впрочем и выхода особого нет :) ). ez, ZF, CI, Doctrine достаточно сыроваты. Они писались в определенных условиях, под определенные нужды.
Поэтому даже средние специалисты часто пишут свое. Хорошие специалисты уже написали и пользуются своим.
P.S. если вы не в курсе, я пишу на PHP в основном.
Лет через 5ть мы, возможно, увидим прогресс. Вопрос какой ценой. За легкость разработки и лишние абстракции всегда надо платить и производительностью и деньгами.
То есть типа под Java нельзя писать raw-html потому что есть фреймворки, а на PHP можно потому что нет другого выбора. Интересная логика.
«На PHP просто нет соответствующих библиотек такого качества»
Ага, библиотеки сами рождаются. Как кошки. А нам остается только ждать пока они появятся.
«Хорошие специалисты уже написали и пользуются своим.»
И конечно же выложить опенсорс их жаба задушит.
Вывод: разговор слепого с глухим :) Глухой не желает слышать призыва «нет библиотек!!!», потому что знает, что их нужно писать самому и выкладывать в опенсорс, и никто кроме тебя этого не сделает. А слепой даже не рассматривает такой возможности, потому что привык довольствоваться текущим положением вещей.
«На PHP просто нет соответствующих библиотек такого качества»
Ага, библиотеки сами рождаются. Как кошки. А нам остается только ждать пока они появятся.
«Хорошие специалисты уже написали и пользуются своим.»
И конечно же выложить опенсорс их жаба задушит.
Вывод: разговор слепого с глухим :) Глухой не желает слышать призыва «нет библиотек!!!», потому что знает, что их нужно писать самому и выкладывать в опенсорс, и никто кроме тебя этого не сделает. А слепой даже не рассматривает такой возможности, потому что привык довольствоваться текущим положением вещей.
Фффф. Жуть.
Перечитайте мои слова и поймите разницу между нельзя и неудобно.
И, да, я не вижу смысла бесплатно раздавать что-либо кроме знаний :) А библиотеки — это уже продукт труда и они должны покупаться.
Так что пишите опенсорс библиотеки — на здоровье. Сейчас ОС плодит горы шлака, в котором сложно найти действительно нужные и качественные вещи.
Перечитайте мои слова и поймите разницу между нельзя и неудобно.
И, да, я не вижу смысла бесплатно раздавать что-либо кроме знаний :) А библиотеки — это уже продукт труда и они должны покупаться.
Так что пишите опенсорс библиотеки — на здоровье. Сейчас ОС плодит горы шлака, в котором сложно найти действительно нужные и качественные вещи.
А еще есть GoogleAppEngine =)
orm sqlalchemy в питоне работает раза в 4 медленнее, чем native-запросы.
красиво, но медленно.
красиво, но медленно.
Интересная ссылка на отзыв об использовании db4o на практике: тут.
GLASS Из всего тулкита к данной теме относится только GemStone/S. Советую взглянуть, если не лениво. Яркий пример Persistence без какого либо кода.
client.Close(); тоже нужно вызывать в finally
Sign up to leave a comment.
Введение в объектно-ориентированные базы данных