Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

20.08.2018

Новости:


Все новости

Точка зрения

Персистентность данных в объектно-ориентированных приложениях

Давнишней мечтой объектно-ориентированных программистов является удобная возможность сохранения состояния своих объектов в промежутках времени между запусками программ (эту возможность для краткости я называю персистентностью объектов). Давнишняя мечта специалистов из сообщества баз данных состоит в том, чтобы мечта программистов стала реальностью. На этом пути были пройдены этапы языков программирования баз данных, систем управления объектно-ориентированными базами данных, объектных расширений языка SQL. Однако по-прежнему объектно-ориентированные программисты сохраняют состояние объектов в простых табличных SQL-ориентированных базах данных и, естественно, страдают от «потери соответствия» концепций используемых языков программирования и SQL-ориентированных баз данных.

Весной 2008 г. редакторы порталов ODBMS.ORG и InfoQ.COM провели две виртуальные панельные дискуссии, в которых в совокупности приняли участие девять специалистов в области объектно-реляционного отображения и объектно-ориентированных систем управления базами данных. Формально дискуссии посвящались обсуждениям различных аспектов персистентности объектов в контексте языка Java, но фактически обсуждался более широкий круг вопросов, связанных с использованием баз данных в приложениях, создаваемых на объектно-ориентированных языках программирования.

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

Итак, вашему вниманию предлагаются материалы панельной дискуссии «Персистентность Java-объектов: положение дел», в первой части которой участвовали Майк Кейт (Oracle), Тед Ньюард (независимый консультант), Карл Розенбергер (db4objects, Inc.) и Крейг Рассел (Sun Microsystems). Участниками второй части дискуссии являлись Хосе Блейкли (Microsoft), Рик Каттелл (консультант), Вильям Кук (University of Texas at Austin), Роберт Грин (Versant) и Элан Сантос (Progress Software).



Комментарии

Страницы комментариев: предыдущая :: 1 :: 2

Сергей Кузнецов, Sun Jul 6 17:31:43 2008:
Alex, я помню два таких случая, оба были связаны с электронными САПР. В середине 1980-х гг. в НИИ Дельта велся большой проект по созданию "красного Крея", Электроники СС-БИС. Для разработки схем и общей архитектуры делалась своя САПР, создаваемая коллективом программистов и инженеров-электронщиков. Им было очень плохо жить без системы управления данными, а мы в то время очень хотели сделать ООСУБД. Я долго приставал к САПРовщикам, расписывал им потенциальные удобства и т.д., но они так и сделали всю свою систему на файлах. В начале 2000-х мы начали заниматься XML-СУБД. Как-то встречались с разработчиками электроники из Intel и расписывали им преимущества XML. Они очень порадовались, но дальще этого дело опять не пошло. Причем в обоих случаях мы ничего не просили, мы только спрашивали, что следует сделать в системе управления данными, чтобы она была им полезна. А один раз человек из области САПР мне честно сказал следующее: мы, мол, и рады бы сказать, что нам нужно, но мы узнаем это только по ходу разработки, а когда САПР уже сделана, становится слишком поздно.
Alex, Fri Jul 4 18:08:02 2008:
Сергей Кузнецов, а с кем из разработчиков САПР Вы общались?
Постоянный читатель, Thu Jul 3 14:55:17 2008:
Думаю, что в общем мнение разработчиков сведется к простоте создания сложных клиент-сервреных систем. Как? да они сами не знают! Им нужно что-то предложить, что бы они могли попробовать.

На самом деле КМК история повторяется. Из доступной мне литературы складывается впечатления что лет 30-40 назад наблюдалась аналогичная ситуация в сфере СУБД. Существовали мощные иерархические и сетевые системы, существовал CODASIL, разработчикам предлагались какие-то технологии и инструменты, но в конце концов победила абсолютно иная, реляционная парадигмы, даже несмотря на то, что ей пришлось развиваться с нуля. Поэтому я скептически отношусь в новым технологиям в рамках старой парадигмы - всё это лишь бантики, свистульки и колокольчики.

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

Мапинг? Кажется, что он маппинг уменьшает количество имен. Но что делать с групповыми операциями, с незапланированными запросами?

ООСУБД? но ведь история развития СУБД привела нас к отдельно взятому серверу баз данных, являющемуся открытой системой, имеющей самотоятельную ценность.... И опять же запросы.

ОРСУБД? Кажется до реальных объектов там еще далеко... и в любом случае надуманно и запутанно с точки зрения системы типов и их соответсвий.

3-й манифест? Но там ясно сказано, что домены - есть инкапсулированные классы. Описывая этот инкапсулированный класс программист что должен сделать? - правильно, ввести новые _имена_ ! Формальая чистота соблюдена, но стала ли система менее сложной в целом?
Сергей Кузнецов, Thu Jul 3 13:56:32 2008:
Мои возможные ответы на вопросы этой дискуссии неявно следуют из моих же статей. На самом деле, ситуация, которую я наблюдаю уже больше двадцати лет, мне просто непонятна. В сообществе баз данных создаются все новые технологии, направленные на поддержку разработки приложений, а разработчики ими не пользуются. Чего здесь больше - политики или техники, мне просто неясно. Очень хотелось бы услышать мнение разработчиков - чего бы на самом деле хотелось им. Однако много лет назад я приставал с аналогичным вопросом к разработчикам САПР, но так и не смог получить ответа. Возможно, здесь та же проблема потери соответствия, но на этот раз между сообществом разработчиков объектно-ориентированных приложений и сообществом СУБД.
аноним, Thu Jul 3 12:30:56 2008:
Уважаемый Сергей.

1) Как бы Вы сами могли ответить на эти вопросы?

2) Озвученная задача "сохранения состояния объектов в промежутках времени между запусками программ", уже сама по себе подразумевает некий подход, некую архитектуру системы. Замечу также, что по сути она является _промежуточной_ задачей, решение которой, как надеются сторонники ООСУБД, позволит содать систему, удовлетворяющую потребностям конечноых пользователей(что, собственно и является сверхзадачей для всей IT-индустрии). Может быть, для решения этой сверхзадачи нужны принципиально иные подходы и архитектуры?


С уважением,
Ваш постоянный читатель
аноним, Thu Jul 3 00:19:12 2008:
Чем больше этой проблемой занимаюсь, тем явственней становится её надуманность. Дело в том, что нет никакой принципиальной сложности в отображении объектной модели на реляционную. Более того, мне до сих пор непонятно на каком этапе могут возникнуть сложности. Реляционная модель реализует механизмы надёжного сохранения и целостности данных, так же формирует словарь, а объектная образует уровень контроллера.

Страницы комментариев: предыдущая :: 1 :: 2

Комментарии заморожены.

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru