Здравствуйте, eao197, Вы писали:
E>Понятно. Но ты, как я понимаю, больше в сторону .Net смотришь?
В смысле? Я смотрю в сторону турагентств. И оказывается, что если единственная девочка в конторе, прошедшая курсы, ушла на обед, то купить у них билет можно только на рейс Новосибирск-Москва-Новосибирск. Потому как выписка происходит исключительно через зеленый терминал. Ибо построить полноценную клиент-серверную систему в принципе невозможно. И, представляя объемы бабла в этом секторе, не думаю что все из-за лени. Просто правила тарификации для всех компаний свои, и из-за этого нельзя написать модульную эффективную клиент-серверную систему. Поддержка полиморфизма помогла бы перенести ту часть логики, которая происходит в голове у кассира, на сервер. E>А в Java, имхо, в этом направлении активно копают.
Ага. И тем не менее, РСУБД по-прежнему рулят со страшной силой. E>С++/CLI пусть идет еще более темным лесом! E>Лично у меня нет никакого желания с ним связываться.
Ага, как говорил старик Буденный: "Да ну их, эти танки".
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Понятно. Но ты, как я понимаю, больше в сторону .Net смотришь? S>В смысле? Я смотрю в сторону турагентств. И оказывается, что если единственная девочка в конторе, прошедшая курсы, ушла на обед, то купить у них билет можно только на рейс Новосибирск-Москва-Новосибирск. Потому как выписка происходит исключительно через зеленый терминал. Ибо построить полноценную клиент-серверную систему в принципе невозможно. И, представляя объемы бабла в этом секторе, не думаю что все из-за лени. Просто правила тарификации для всех компаний свои, и из-за этого нельзя написать модульную эффективную клиент-серверную систему. Поддержка полиморфизма помогла бы перенести ту часть логики, которая происходит в голове у кассира, на сервер. E>>А в Java, имхо, в этом направлении активно копают. S>Ага. И тем не менее, РСУБД по-прежнему рулят со страшной силой.
Значит возможностей РСУБД в этом направлении с лихвой хватает. И совсем не факт, что супер-пупер ООСУБД (если такое вообще возможно) сделает прорыв в этой области. А Java я упоминул, потому, что там, как мне помниться, в J2EE были работы по прозрачной сериализации Java-объектов в БД и по такому же прозрачному подъему из БД. Кроме того, код Java объектов исполнялся внутри EJB контейнера на серверной стороне. Т.е. для клиента связка EJB+РСУБД выглядит практически так же, как ты хочешь это видеть в ООСУБД.
А что касается задачи, то, имхо, ее сложность и объем (насколько я себе могу представить) не позволяют предположить, что узким местом при ее решении будет СУБД. Имхо, она вполне ляжет на РСУБД + некая логика на стороне сервера приложений.
E>>С++/CLI пусть идет еще более темным лесом! E>>Лично у меня нет никакого желания с ним связываться. S>Ага, как говорил старик Буденный: "Да ну их, эти танки".
Какое-то жуткое засилие дот-нетчиков здесь, нас, C++ программистов, даже понять не хотят!
Я еще готов поверить, что благодоря Mono и DotGNU программы на C# будут переносимыми. Но вот пока C++/CLI не является ANSI C++ стандартом, заморачиваться я на него не хочу. И как показывает топик Будущее С++/CLI
Sinclair пишет:
> E>Понятно. Но ты, как я понимаю, больше в сторону .Net смотришь? > В смысле? Я смотрю в сторону турагентств. И оказывается, что если > единственная девочка в конторе, прошедшая курсы, ушла на обед, то > купить у них билет можно только на рейс > Новосибирск-Москва-Новосибирск. Потому как выписка происходит > исключительно через зеленый терминал. Ибо построить полноценную > клиент-серверную систему в принципе невозможно.
А почему сразу "в принципе"? Особенно когда она уже ЕСТЬ?
> И, представляя объемы бабла в этом секторе, не думаю что все из-за > лени. Просто правила тарификации для всех компаний свои, и из-за этого > нельзя написать модульную эффективную клиент-серверную систему.
Почему? Соединяемся с сервером компании и спрашиваем: "а сколько стоит
билет от ... до ... ?". Мы делали подобную систему, только для биржевых
площадок.
Причем система для этого нужна даже не особо большая — даже во время
пиковых нагрузок не будет больше сотен запросов в секунду.
> Поддержка полиморфизма помогла бы перенести ту часть логики, которая > происходит в голове у кассира, на сервер.
eao197 пишет:
> Значит возможностей РСУБД в этом направлении с лихвой хватает. И > совсем не факт, что супер-пупер ООСУБД (если такое вообще возможно) > сделает прорыв в этой области. А Java я упоминул, потому, что там, как > мне помниться, в J2EE были работы по прозрачной сериализации > Java-объектов в БД и по такому же прозрачному подъему из БД.
Тут разве еще не говорили? http://www.hibernate.org/ — OR-mapping для
Java. Поддерживает отображение отношений, _полиморфзм_ (он замечательно
ложится на РСУБД, кстати) и еще кучу фич.
И что характерно — все работает и реально используется.
Здравствуйте, Cyberax, Вы писали:
C>eao197 пишет:
>> Значит возможностей РСУБД в этом направлении с лихвой хватает. И >> совсем не факт, что супер-пупер ООСУБД (если такое вообще возможно) >> сделает прорыв в этой области. А Java я упоминул, потому, что там, как >> мне помниться, в J2EE были работы по прозрачной сериализации >> Java-объектов в БД и по такому же прозрачному подъему из БД.
C>Тут разве еще не говорили? http://www.hibernate.org/ — OR-mapping для C>Java. Поддерживает отображение отношений, _полиморфзм_ (он замечательно C>ложится на РСУБД, кстати) и еще кучу фич.
C>И что характерно — все работает и реально используется.
Да я собственно про Java и упоминал, имея в виду Hibernate и EJB контейнеры. У нас несколько команд используют его в связке с JBoss -- вроде никто особенно не жаловался.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Плохо, значит, известно. Те же ЖД билеты у нас уже через сравнительно C>нормальную систему продают.
Это от того, что ЖД билеты продает ровно одна организация, у которой единые тарифы. Модель проста как грабли, поэтому удалось ее автоматизировать при помощи РСУБД.
Причем прикол: для авиабилетов есть веб-сайты. Еще год назад я вообще не мог удаленно узнать, какие поезда ходят между Москвой и Питером, и сколько стоят билеты на них. C>Да и ничего в таких системах сверхсложного C>нет — максимум десятки простых запросов в секунду.
Простые запросы? Ты вообще когда-нибудь авиабилет покупал? Попробуй рассказать, сколько мне будет стоить билет Новосибирск-Франкфурт-Стамбул-Москва-Новосибирск. С учетом скидок и ограничений.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Из-за дьявольски сложного семейства почтовых стандартов.
Я же сказал "банального" C>Можешь еще C>CORBA 3 вспомнить, которую C>в полном объеме вообще никто не реализует. C>В SMTP-релее как раз хранилище не особо важно. Там и обычной FS хватает.
Ну-ну. Видел я эти FS-релеи. Самописаный релей (Java + MS SQL) рвал их примерно раз в полсотни по производительности. Не говоря уже об устойчивости к сбоям. Там, где при сбое питания надо очередь руками расчищать
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Плохо, значит, известно. Те же ЖД билеты у нас уже через сравнительно C>>нормальную систему продают. S>Это от того, что ЖД билеты продает ровно одна организация, у которой единые тарифы. Модель проста как грабли, поэтому удалось ее автоматизировать при помощи РСУБД. S>Причем прикол: для авиабилетов есть веб-сайты. Еще год назад я вообще не мог удаленно узнать, какие поезда ходят между Москвой и Питером, и сколько стоят билеты на них.
Sinclair пишет: > C>В SMTP-релее как раз хранилище не особо важно. Там и обычной FS хватает. > Ну-ну. Видел я эти FS-релеи. Самописаный релей (Java + MS SQL) рвал их > примерно раз в полсотни по производительности. Не говоря уже об > устойчивости к сбоям. Там, где при сбое питания надо очередь руками > расчищать
qmail использует ФС для хранения сообщений. И ничего — один из наиболее
производительных mta.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Sinclair пишет:
> C>Плохо, значит, известно. Те же ЖД билеты у нас уже через сравнительно > C>нормальную систему продают. > Это от того, что ЖД билеты продает ровно одна организация, у которой > единые тарифы. Модель проста как грабли, поэтому удалось ее > автоматизировать при помощи РСУБД.
А что, если модель сложная, то РСУБД автоматически отпадают? )) Могу
ткнуть носом в SAP, в котором сложная модель с 10000 таблиц.
> Причем прикол: для авиабилетов есть веб-сайты. Еще год назад я вообще > не мог удаленно узнать, какие поезда ходят между Москвой и Питером, и > сколько стоят билеты на них.
А это проблемы наших авиакомпаний.
> C>Да и ничего в таких системах сверхсложного > C>нет — максимум десятки простых запросов в секунду. > Простые запросы? Ты вообще когда-нибудь авиабилет покупал? Попробуй > рассказать, сколько мне будет стоить билет > Новосибирск-Франкфурт-Стамбул-Москва-Новосибирск. С учетом скидок и > ограничений.
Считаем маршрут от Новосибирска до Франкфурта (0 запросов — все станции
вполне можно хранить в памяти), затем считаем цену от Новосибирска до
границы (опять же — 0 запросов) и проверяем доступность (1-2 запроса)
свободных мест. Затем просим компанию, ответственную за перевозку от
границы до Франкфурта сделать тоже самое.
И я уж не говорю, что такие сложные заказы едва ли будут 1% от всех заказов.
Sinclair пишет:
> C>Из-за дьявольски сложного семейства почтовых стандартов. > Я же сказал "банального"
Слова "банальный", "корректный" и "email" — несовместимы. Даже банальный
релей должен понимать все форматы адресов, если хочет быть корректным.
> C>Можешь еще > C>CORBA 3 вспомнить, которую > C>в полном объеме вообще никто не реализует. > C>В SMTP-релее как раз хранилище не особо важно. Там и обычной FS хватает. > Ну-ну. Видел я эти FS-релеи. Самописаный релей (Java + MS SQL) рвал их > примерно раз в полсотни по производительности. Не говоря уже об > устойчивости к сбоям. Там, где при сбое питания надо очередь руками > расчищать
А причем здесь ООБД и РСУБД?
ЗЫ: а вообще, рулит QMail. "7 лет и ни одной новой дырки" (c).
Здравствуйте, Cyberax, Вы писали:
C>А что, если модель сложная, то РСУБД автоматически отпадают? )) Могу C>ткнуть носом в SAP, в котором сложная модель с 10000 таблиц.
могу ткнуть носом в правила... но могу сразу забанить, без тыканья. выбор за тобой.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, Sinclair, Вы писали:
S>С моей точки зрения, ООБД — это не столько хранилище, сколько средство создания серверов приложений. Т.е. замкнутых провайдеров определенной функциональности. Современные RDBMS вполне могут использоваться как самостоятельные app-сервера. Вот только программировать мало-мальски сложные сервера приложения с их помощью довольно-таки затруднительно. Хочется некоторого упрощения. Вот авторы ODMG сели в лужу именно благодаря тому, что декларировали, с одной стороны, наличие поведения у объектов (потому как иначе бы их никто всерьез не воспринял), а с другой стороны решили "пусть это поведение реализует кто-нибудь другой". В итоге ODMG так и остался мертворожденным. В том виде, в котором он существует, он не в состоянии конкурировать с RDBMS.
Вы просто читаете мои мысли.
Я тоже убежден в том, что ООСУБД ака Versant могут быть действительно полезны именно в озвученой вами парадигме.
Джентельмены, с удовольствием прочел ваши мнения, позвольте высказать свое.
Сервера приложений (как и многое в нашей жизни) делятся на две категории:
1. Бизнес-объекты полностью инкапсулированы и полиморфно работают только сами в себе.
2. Бизнес-объекты прокачиваются через набор сервисов, и те делают с ними те вещи которые называются бизнес-логикой.
"Правильный" сервер-приложений, по-моему мнению, это оба этих подхода в одном флаконе. И таким образом — в зависимости от требований, при построении бизнес-логики обуславливает крен в ту или иную сторону.
Что такое "чистая" ООБД в моем понимании. Это некоторая БД оперирующая объектами и реализующая, по крайней мере, пункт 1. То есть, ни одна сволочь не может добраться до состояния объектов минуя реализацию бизнес-объекта. В том числе и декларативный запрос. Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов. По этому поводу, еще хочется сказать. К сожалению, в текущих версиях ООДБ основным считают навигационный доступ, а запросы — некоторая дополнительная сущность. Мне это не нравится.
Насколько она должна держать п2 — не знаю. Но отрицать что бизнес-объект может быть максимально прост и оперироваться сервисами, нельзя. Это решение задачи предложенной eoa197.
[to eao197]
Что касает предложенной тобой заморочки с изменяемыми реализациями. Иногда ее сильно нехватает. С ней, можно было-бы сократить паттерны GoF. Но это палка о двух концах. При этом нужно учитывать, что она не только содержит в себе все недостатки множественного наследования, но и усугубляет их. Если ты попробуешь формализовать процесс создания нового объекта, то ты получишь нехилую кучу требований которые трудно будет выполнять. Если сейчас спросить 10 программистов С++, в каком порядке выполняются конструкторы в объекте с множественным наследованием, то дай бог хоть один уверенно ответит (хотя тут догадаться несложно). Недаром в последних языках используются именно объекты с множественным наследованием интерфейсов без реализаций. Если bvb пользоваться + дополнительно сервисы — то проблемы сами разрешаться.
. А именно — практическая невозможность построить эффективный механизм запросов не имея полного контроля хранилища.
Что касается перегрузки на клиента — то на это наплевать. Кэширование на клиенте, так на клиенте. Если при этом выполняется п1, то на здоровье. Такой механизм все-таки возможен (правда по первым прикидкам наверное не эффективен).
Что касается билетов. Была некоторая рекламная статья, от какой-то OODB. Какая не помню (давно было), но прикольно то что они как раз и обналичивали кассы авиабилетов. Вобщем замена Oracle на OODB дало очень большой прирост в производительности. Но чего-то сразу ее не нашел. Так что, верьте на слово.
С уважением, Gleb.
PS: IMХО Не советую пользовать C++/CLI. Только для системных вещей требующих unmanaged код, которых не так уж много. Но это вопрос другого флейма.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
GZ>Джентельмены, с удовольствием прочел ваши мнения, позвольте высказать свое.
Очень интересное мнение.
GZ>[to eao197] GZ>Что касает предложенной тобой заморочки с изменяемыми реализациями. Иногда ее сильно нехватает. С ней, можно было-бы сократить паттерны GoF. Но это палка о двух концах. При этом нужно учитывать, что она не только содержит в себе все недостатки множественного наследования, но и усугубляет их. Если ты попробуешь формализовать процесс создания нового объекта, то ты получишь нехилую кучу требований которые трудно будет выполнять. Если сейчас спросить 10 программистов С++, в каком порядке выполняются конструкторы в объекте с множественным наследованием, то дай бог хоть один уверенно ответит (хотя тут догадаться несложно). Недаром в последних языках используются именно объекты с множественным наследованием интерфейсов без реализаций. Если bvb пользоваться + дополнительно сервисы — то проблемы сами разрешаться.
Если не сложно, GlebZ, об выделенном фрагменте подробнее. Я не очень понял откуда взялось множественное наследование, т.к. я о нем не говорил вроде.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов. По этому поводу, еще хочется сказать. К сожалению, в текущих версиях ООДБ основным считают навигационный доступ, а запросы — некоторая дополнительная сущность. Мне это не нравится.
Думаю вполне уместным будет выложить здесь мое мнение относительно языков запросов и ООСУБД.
Из личной практики работы с продуктами Versant я вынес следующее. Запросы нужно использовать при работе с ООСУБД как можно реже. Причин тут несколько.
Во-первых, чувствуется слабость оптимизаторов (особенно это касается FastObjects). Как результат приходтся более внимательно писать приложение и часть работы по оптимизации выполнять самому, не надеясь на то, что оптимизатор выберет наилучшее решение. Но главное — нужно так строить сами объектные структуры, чтобы заменить запросы прямой навигацией. Ко всему и ограниченность имеющегося языка запросов (FastObjects) не способствует тому, чтобы было желание запросы активно использовать. Как ни странно, указанный подход вполне срабатывает. ООСУБД предлагают достаточно инструментов, которые реально замещают запросы во многих ситуациях.
Во-вторых, сложна судьба самого языка запросов ООСУБД. Существует спецификация ODMG, которая определяет язык запросов OQL. Именно на базе OQL и строятся сегодня языки запросов разных СУБД. Но основная беда OQL в том, что в период его создания у разработчиков было немерянное желание сделать его максимально похожимна SQL, что и породило массу проблем и вопросов (ака "что вернет запрос ... ?"). Производители ООСУБД, тем не менее, вынуждены поддерживать то, что включено в спецификацию и развивать эту поддержку. Но логика развития демонстрирует странные факты. OQL, существующий уже давно, не вызывает особых симпатий, а разработчики, например на Java, предпочитают более адаптированный к их нуждам JDOQL.
По моим личным впечатлениям декларативные языки запросов вообще не подходят для работы с ООСУБД — они не соответствуют объектной парадигме этих систем, вступая с ней в противоречие. Более понятным и продуктивным здесь может быть процедурный/функциональный подход к написанию запросов.
И, кстати, производители ООСУБД этот подход поддерживают, хотя пока и нельзя сказать, что он сильно развит (далее все гипотетически, конкретных продуктов, работающих подобным образом я не знаю). Т.е. вместо OQL запроса вида: "SELECT * From ObjectClass Where ObjectClass.atrrib = const_Object" мы в ОО-программе пишем что-то вроде "database.GetCollecttion('ObjectClass', constObject.equals)" и получаем результат-коллекцию. Обычно это коллекция ссылок на объекты.
Но уже и в этом примере видно, что включение объекта Object в результирующую коллекцию происходит в зависимости от того, какой результат возвратит метод cons_Object.equals(Object). Как оптимизировать такие запросы, если код метода equals может быть очень сложным? Где отрабатывать код метода? Пока что ответов на эти вопросы нет. Но похоже производители движутся именно в этом направлении (и в первую очередь об этом свидетельствует рост популярности функциональных языков запросов: JDOQL, XQuery, WebOQL ... ). Т.е. методы отрабатываются на сервере приложений, а база данных только предоставляет данные для сервера приложений, помогая ему чем может (индексы, транзакции ... ).
Чтобы создать систему, действительно способную оптимизировать такие запросы, разработчикам ООСУБД еще предстоит много и много потрудиться (адаптивные методы оптимизации еще не вышли научных институтов), но формально реализовывать системы, в которых подобные механизмы будут работать, сегодня уже никто не мешает. Весь инструментарий доступен и в целом вполне удобен при использовании (базируется на использовании итераторов, пространств классов и т.п.). Просто вопросы оптимизации, увы, пока лежат на разработчиках подобных систем.
Здравствуйте, eao197, Вы писали:
E>Если не сложно, GlebZ, об выделенном фрагменте подробнее. Я не очень понял откуда взялось множественное наследование, т.к. я о нем не говорил вроде.
Да проблема та же что я и описал. При инициализации объекта, непонятно в каком порядке будут вызываться конструкторы. Но там хоть данные во многом разделены. А тут еще усугубляется тем, что все классы навешаны на один и тот же инстанс. В результате, они должны инициализировать одно и то же состояние, и обязательно в каком-то порядке. В результате — бизнес-логика класса начинает значительно усложняться. Сразу непонятно, вот мы создаем объект. Например мы создаем объект A. Но у нас есть также реализация B, в которой тоже есть некоторая логика создания. То есть, мы обязаны его также поднять. И в каком порядке они должны вызываться? В силу того что при этом состояние на момент выполнение конструктора B очень непонятно, то порядок вызова быть обязан. Ну слово за слово, и пойдет написание требований которые не каждый выучит. Хотя формализация множественного наследования для OODB была, я, например, сейчас и не вспомню что там было написано.
Да уж. Вы практически в точку указали почему OQL нельзя использовать. Вы указали почему — построить нормальный язык очень сложно. Но вы не сказали почему все-таки производители за это не беруться, и почему они пытаются выполнять (даже в новых продуктах) требования ODMG. Мне пока не верится, что это невозможно.
Что касается оптимизации многомерных запросов, то это я пока опущу. Просто я пока не обладаю необходимыми знаниями. А работы по этому профилю есть и ведутся.
А вот что касается самого языка запросов, напишу несколько более.
Повторю свою фразу:
Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов.
То есть. Мы привыкли к SQL. Даже скажу больше. Мы подсели на SQL. Одной выборкой получить все данные. Поэтому, над необходимостью языка запросов для коммерческой привликательности OOБД, я думаю говорить не стоит.
Но. БД обладает некоторым свойством. И это свойство — то, что это практически единственное место где может находиться практически неогранниченное кол-во объектов. Мы привыкли к тому, что SQL служит для перегонки данных туда и обратно. Но есть также и хранимые процедуры. И у них есть величайшее свойство — они могут обрабатывать неограниченное кол-во данных. Так почему не вделать в язык то же самое.
Что этому мешает. Этому мешает то, что в отличие от хранимых процедур, где есть процедура компиляции в течении которой БД получает максимум информации для эффективного выполнения, у нас есть неподконтрольные языки. Но сейчас ситуация изменилась. Наступают управляемые языки которые не хранятся в непонятном коде зависимом от процессора, а написаны на некотором простом языке (CLI, байт-код). Для неуправляемого языка такое сделать практически нереально. Но для CLI — кто мешает? По CLI можно вполне вывести всю информацию о выполнении и о том, что может понадобиться при этом выполнении. Плюс к этому, не помешает сбор статистики выполнения.
Что мы получаем в результате. То, что мы можем производить действия на большим набором объектов в одной команде. Вот и все что я хотел сказать.
Во многом эта разница между декларативным подходом и навигационном напоминает спор между императивными и функциональными языками. То что предлагает функциональный язык, вполне возможно сделать на императивном. Просто больше кода получится.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Если не сложно, GlebZ, об выделенном фрагменте подробнее. Я не очень понял откуда взялось множественное наследование, т.к. я о нем не говорил вроде. GZ>Да проблема та же что я и описал. При инициализации объекта, непонятно в каком порядке будут вызываться конструкторы. Но там хоть данные во многом разделены. А тут еще усугубляется тем, что все классы навешаны на один и тот же инстанс. В результате, они должны инициализировать одно и то же состояние, и обязательно в каком-то порядке. В результате — бизнес-логика класса начинает значительно усложняться. Сразу непонятно, вот мы создаем объект. Например мы создаем объект A. Но у нас есть также реализация B, в которой тоже есть некоторая логика создания. То есть, мы обязаны его также поднять. И в каком порядке они должны вызываться? В силу того что при этом состояние на момент выполнение конструктора B очень непонятно, то порядок вызова быть обязан. Ну слово за слово, и пойдет написание требований которые не каждый выучит. Хотя формализация множественного наследования для OODB была, я, например, сейчас и не вспомню что там было написано.
Здесь произошло какое-то недопонимание. Я не говорил про множественное наследование. Я говорил, что при поднятии из БД объект может превратиться в совершенно разные объекты. Например, пусть есть класс surface_t, который в БД представляется типом:
class surface_t
{
material_t * m_material;
geometry_t m_geometry;
};
Этот класс в программе редактирования чертежей имеет вид:
class surface_t
{
protected :
material_t * m_material;
geometry_t m_geometry;
editor_t * m_editor;
public :
...
// Запросить параметры для редактора (цвет, стиль линии, стиль заливки и т.д.)void
properties( editor_properties_t & props ) const;
// Изменить значение указанного параметра (цвета, стиля линии и т.д.)void
change_properties(
const editor_property_t & prop,
editor_undo_redo_t & undo_redo );
// Отобразить объект на чертеже (с учетом группировки, выделения и т.д.)void
paint(
editor_paint_device_t & device,
editor_selection_t & selection ) const;
};
А в программе печати чертежей:
class surface_t
{
protected :
material_t * m_material;
geometry_t m_geometry;
device_properties_t * m_properties;
public :
...
// Отобразить на указанном устройстве.void
draw( paint_device_t & device ) const;
...
};
Т.е. это один и тот же класс, который в программах выглядит по разному. Здесь нет никакого множественного наследования. Речь идет лишь о том, что transient-атрибуты и код методов класса в разных программах реализуется разными библиотеками. Здесь нет никаких проблем с порядком инициализации объектов при извлечении из БД. Фокус в том, что разные in-memory представления объекта превращаются в одинаковое представление объекта в БД.
В чем здесь сложность -- это согласованность состояний одного и того же объекта в разных приложениях. Если классом в разных программах управляет разный код, то обеспечение согласованного состояния persistent атрибутов является основным вопросом.
Когда я в аспирантуре занимался ООСУБД, я только подошел к этому вопросу. Решать его уже было некогда. Но, например, можно предложить что-то вроде идиомы PImpl из C++:
class surface_data_t
{
material_t * m_material;
geometry_t m_geometry;
};
class surface_t
{
surface_data_t m_data;
};
Т.е. типы surface_data_t и surface_t являются сохраняемыми, но только тип surface_t может иметь разные реализации в разных приложениях. Тип surface_data_t должен иметь одинаковую реализацию везде. Т.е., на физическом уровне, есть одна общая библиотека с кодом surface_data_t и множество частных библиотек с кодом surface_t.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Alexey Rovdo, Вы писали:
GZ>Да уж. Вы практически в точку указали почему OQL нельзя использовать. Вы указали почему — построить нормальный язык очень сложно. Но вы не сказали почему все-таки производители за это не беруться, и почему они пытаются выполнять (даже в новых продуктах) требования ODMG. Мне пока не верится, что это невозможно.
Мне кажется, что производители коммерческих продуктов берутся за все это только по одной причине — желание соответствовать как можно большему числу стандартов. Проприетарные решения не в чести у покупателей, а альтернативы у ODMG пока нет (хотя бурное развитие JDO можно рассматривать как заявку — и этот путь, полагаю, более верен, чем путь ODMG).
GZ>Запросы — это не столько получение некоторого набора объектов, а еще инструмент выполнения некоторых действий на некоторым множеством объектов.
Действительно, групповые операции над данными вообще не предусмотрены никакими спецификациями ООП (по крайней мере я таких не знаю). Как результат, производители вынуждены придумывать свои проприетарные решения. Так, к примеру, в ООСУБД VDS есть некоторые рудиментарные средства, но вот в JDO вроде пока ничего такого ...
