Вообщем ситуация такая: я уже не знаю, куда зашли разговоры в соседней ветке "Объектно-ориентированные БД: основные принципы, ..." поэтому хочется некоторые вещи выделить отдельно.
Вот, например, на форуме SQL.ru было высказано следующее мнение: (Хочется узнать что думаете об этом Вы)
Джентельмены.
Давайте забудем (и по крайней мере сделаем вид что отвлеклись от) все что здесь уже говорилось про объектные базы и Версант. Предлагаю более вообще не обсуждать теорию.
Простейшая формулировка как хранит данные и работает Версант (в отличие от реляционных баз):
1. Версант — это "якобы объектное хранилище". Методы объектов не выполняются и не хранятся. Хранятся только данные (структуры данных). Как в РСУБД. Буду нывать далее структурами данных Версант. Струры данных самые разнообразные — это и массивы, коллекции (вложенные коллекции), и указатели на другие объекты и пр. На эти коллекции маппируются вложенные коллекции классов (1-n). На указатели на объекты — ссылки n-m.
2. Версант (ядро) ничего не знает про Яву, с++, Smalltalk, whatever.
Средства доступа к Версанту на Яве "преобразуют" Ява объекты в структуры данных Версант. Средства доступа к Версанту на с++ "преобразуют" с++ объекты в структуры данных Версант. Предыдущие 2 предложения применимы к любым "обектным" языкам. Не буду их копировать.
3. Средства доступа.
1. Командная строка (аля sqlplus). Сама по себе не объектна. Соответственно, все запросы из командной строки возвращают структуры данных Версант. И тупо их печатают.
2. Средства доступа к Версанту на Яве.
2.1 Доступ по спецификации JDO. Это средство доступа ответственно за преобразование пришедших данных Версант в классы Ява. В соответствии со стандартом JDO, имеет свой собственный язык JDOQL. Это же средство ответственно за трансляцию JDOQL в запросы/вызовы процедур/чтоугодно нативное для Версант.
2.2 Доступ по АПИ Версант. Обеспечивает доступ непосредственно к структурам данных Версант. Запросы (по моему) на языке VQL. Имея этот доступ, можно реаливать любой мэппинг пришедших структур данных Версант на классы Ява.
2.3 Доступ по технологии Transparent Persistance. Просто вызывая функции Ява но изменению значения полей объектов, автоматически происходит преобразование данной системой доступа объектов в структуры данных Версант и их запись. Основной плюс — полное отсутствие обращений по обслуживанию сохранения объектов (поэтому и называется Transparent...)
2.4 Доступ по спецификации JDBC. Не знаю, не работал.
Единственное, что нельзя релизовать с точки зрения хранения структур в Яве — это с++ множественное наследование. Устраняется проблема путем либо интерфейсов, либо ручного маппинга.
Ессно, есть средства доступа для других объектных языков.
4. Средства ссылочной целостности — полные аналоги check constraints, foreign key, primary key. Есть хранимые процедуры и триггеры.
5. План запросов — есть хрень показывающая план запроса.
Здравствуйте, BaZa, Вы писали:
BZ>Вообщем ситуация такая: я уже не знаю, куда зашли разговоры в соседней ветке "Объектно-ориентированные БД: основные принципы, ..." поэтому хочется некоторые вещи выделить отдельно.
BZ>Вот, например, на форуме SQL.ru было высказано следующее мнение: (Хочется узнать что думаете об этом Вы)
Так а в чем, собственно, вопрос состоит? Согласны ли читатели форума с приведенным мнением?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
BZ>>Вот, например, на форуме SQL.ru было высказано следующее мнение: (Хочется узнать что думаете об этом Вы)
E>Так а в чем, собственно, вопрос состоит? Согласны ли читатели форума с приведенным мнением?
Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)?
Здравствуйте, BaZa, Вы писали:
BZ>>>Вот, например, на форуме SQL.ru было высказано следующее мнение: (Хочется узнать что думаете об этом Вы)
E>>Так а в чем, собственно, вопрос состоит? Согласны ли читатели форума с приведенным мнением?
BZ>Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)?
Имхо, хранение методов возможно только для управляемых языков (типа C#, Java, Python, Ruby, Smalltalk, ...). Если речь о C++, то сделать хренение методов объектов в БД будет на порядок (а то и на несколько) сложнее. Да и не понятно, будет ли в случае C++ от этого какая-то польза.
А дальше разработчики ООСУБД должны сами для себя решить, нужна ли им такая функциональность или нет. Например, если ООСУБД предназначается для использования в CAD системах, то от методов объектов в БД пользы может никакой и не быть. Равно как и в случаях, когда ООСУБД используется для накопления больших объемов измерительных данных (хотя не знаю, может здесь от методов какая-то польза и будет). А если ООСУБД предназначена для enterprise-задач, то от помещения части бизнес-логики в методы хранящихся в БД объектов польза может быть существенная.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BaZa, Вы писали: BZ>Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)?
Ну, вообще-то, лично я бы постеснялся назвать базу без хранения методов объектно-ориентированной. Поскольку из пяти концепций объектно-ориентированного программирования поддерживаются только две: идентифицируемость и наследование. О поведении, вместе с инкапсуляцией и полиморфизмом, можно забыть. Не вполне очевидно, нужно ли вообще наследование без полиморфизма.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, BaZa, Вы писали: BZ>>Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)? S>Ну, вообще-то, лично я бы постеснялся назвать базу без хранения методов объектно-ориентированной. Поскольку из пяти концепций объектно-ориентированного программирования поддерживаются только две: идентифицируемость и наследование. О поведении, вместе с инкапсуляцией и полиморфизмом, можно забыть. Не вполне очевидно, нужно ли вообще наследование без полиморфизма.
А я бы нет
Ведь база данных -- это хранилище данных. Для чего там код?
Чтобы исполнятся во время выполнения запросов на серверной стороне, например.
Ok. Здесь это было бы полезно. Может быть. А может быть было бы достаточно в языке запросов простых примитивов сравнения.
Например, если БД содержит огромное количество структурированной измерительной информации (Objectivity в CERN, как мне помниться, как раз для этого и применялась), то большинство объектов в ней вообще не нуждаются в методах. Или БД, которые содержат чертежи из CAD систем. Большинство объектиков в них будут какими-нибудь точками, многоугольниками, ломанными и окружностями. Для которых поддержка методов в БД так же может быть избыточной. Для таких БД вообще поддерживать методы не имеет смысла. Но вот объектную-ориентированность они поддерживать должны -- извлеченный из БД объект должен становиться точно таким же объектом в программе, которым он был до записи в БД.
Или для того, чтобы закачиваться на сторону клиента вместе с объектом. То же может быть. На примере Java-апплетов что-то подобное уже изобреталось.
Только может быть и другая точка зрения. У каждого клиента может быть свой интерфейс к данным. Т.е. фактически, объект SomeObject, который лежит в БД может при загрузке в одного клиента иметь совсем другой интерфейс, чем при загрузке в другого клиента. Например, класс Point для чертежа CAD системы может иметь несколько реализаций (но одно представление данных) -- одна реализация для использования в редакторе чертежей, одна реализация для использования в программе печати чертежей, одна реализация для программы подсчета количества требуемых для реализации нарисованной на чертеже детали материалов и т.д. В таких условиях в централизованном хранении методов классов на сервере нет смысла.
Так же, если класс объекта в БД может иметь различные реализации в коде клиентов, не понятно, какую из реализаций какого-то метода объекта использовать при выполнении запроса. Запрос от редактора чертежей -- это одно. А запрос от программы печати чертежа -- это уже совсем другое.
Если речь идет о неуправляемых языках, таких как ObjectPascal или C++, то хранение методов объектов в БД -- это что вообще? Наличие dll-ки рядом с БД и ее ручная подгрузка сервером БД с реализацией обращений к функциям из этой dll?
В некоторых случаях создание таких dll будет настолько трудоемкой задачей, что клиенты БД просто не будут этой возможностью пользоваться.
В моем понимании ООБД -- это прежде всего поддержка понятия наследования по отношению к хранящимся в ней данным. Инкапсуляция и полиморфизм -- это уже поведение, а не данные. А поведение определяется программой, которая данные использует. Но никак не данными.
Хотя ООБД настолько размытое понятие, что каждый волен не только понимать под этим термином все, что угодно. Но и реализовывать ООБД по собственному вкусу и цвету. И, что интересно, находить области применения для реализованных в БД возможностей.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Ведь база данных -- это хранилище данных. Для чего там код?
Занятный поинт E> E>Чтобы исполнятся во время выполнения запросов на серверной стороне, например. E>Ok. Здесь это было бы полезно. Может быть. А может быть было бы достаточно в языке запросов простых примитивов сравнения.
Гм. Простые примитивы сравнения уже есть. В RDBMS. Почему-то оказывается, что их не хватает. Если хватает, то зачем какие-то ОО в названии? E>Например, если БД содержит огромное количество структурированной измерительной информации (Objectivity в CERN, как мне помниться, как раз для этого и применялась), то большинство объектов в ней вообще не нуждаются в методах.
Как, впрочем, и в объектах. Я плохо знаком с тем, что хранит CERN. Подозреваю, что у них с теми объектами, которые мы привыкли видеть в ООП, общего мало или вообще ничего.
Кстати, я встречал такое мнение, что ООБД — это "способ придания семантики данным типа BLOB". E>Или БД, которые содержат чертежи из CAD систем. Большинство объектиков в них будут какими-нибудь точками, многоугольниками, ломанными и окружностями.
Пардон за оффтоп, но можно мне вообще объяснить, зачем чертежи CAD систем хранить в БД? Почему не использовать более традиционное хранилище? Я еще понимаю GIS-системы: там есть и многопользовательская работа с едиными данными, и нетривиальные запросы (которые имеет смысл исполнять в клиент-серверной архитектуре). А в CAD-то зачем? Чертеж есть вроде как неделимая сущность... Там вообще на серверной стороне даже структуры вроде не надо. E>Для которых поддержка методов в БД так же может быть избыточной. Для таких БД вообще поддерживать методы не имеет смысла. Но вот объектную-ориентированность они поддерживать должны -- извлеченный из БД объект должен становиться точно таким же объектом в программе, которым он был до записи в БД.
Это не имеет никакого отношения к объектной ориентированности. Точнее, объектная ориентированность здесь не имеет отношения к базе данных. Если подходить с такой мерой, то окажется, что даже dBase поддерживает объектную-ориентированность, поскольку объект, записанный в БД, становится точно таким же объектом при чтении. Какой объект? Да тот самый, который реализует интерфейс IDataRow. E> E>Или для того, чтобы закачиваться на сторону клиента вместе с объектом. То же может быть. На примере Java-апплетов что-то подобное уже изобреталось.
E>Только может быть и другая точка зрения. У каждого клиента может быть свой интерфейс к данным. Т.е. фактически, объект SomeObject, который лежит в БД может при загрузке в одного клиента иметь совсем другой интерфейс, чем при загрузке в другого клиента.
Именно это и есть то, чего хотелось бы избежать. Это нарушение инкапсуляции, а стало быть — неплохой способ выстрелить в ногу себе и окружающим. Объяснение чуть ниже: E>Например, класс Point для чертежа CAD системы может иметь несколько реализаций (но одно представление данных) -- одна реализация для использования в редакторе чертежей, одна реализация для использования в программе печати чертежей, одна реализация для программы подсчета количества требуемых для реализации нарисованной на чертеже детали материалов и т.д.
Ну, ООП в таких случаях говорит — объект обязан реализовывать несколько интерфейсов. E> В таких условиях в централизованном хранении методов классов на сервере нет смысла.
Только централизованная реализация этих интерфейсов позволяет гарантировать целостность объектов. Это ты конечно здорово придумал — иметь разные реализации. Ага, один клиент использует пару методов A и B. A переводит объект из одного целостного состояния (1) в другое (2) , и B этим пользуется — он точно знает, что никакого состояния 3 быть не может. А другой клиент использует метод С, который чихать на это хотел, и переводит тот же объект в состояние, непонятное для С. Поздравляем, выстрел в ногу произведен.
Более того, мы вынуждены доверять каждому клиенту. Представь себе банковскую систему. Никакого поведения в базе нет. Клиент вытаскивает к себе банковский счет, и оппа! у него на миллон долларов больше.
E>Так же, если класс объекта в БД может иметь различные реализации в коде клиентов, не понятно, какую из реализаций какого-то метода объекта использовать при выполнении запроса. Запрос от редактора чертежей -- это одно. А запрос от программы печати чертежа -- это уже совсем другое.
Вот именно. Поэтому классу объекта в клиент-серверной БД крайне противопоказано иметь реализации на клиенте. Чтобы не было понятно, какую реализацию использовать. E> E>Если речь идет о неуправляемых языках, таких как ObjectPascal или C++, то хранение методов объектов в БД -- это что вообще? Наличие dll-ки рядом с БД и ее ручная подгрузка сервером БД с реализацией обращений к функциям из этой dll? E>В некоторых случаях создание таких dll будет настолько трудоемкой задачей, что клиенты БД просто не будут этой возможностью пользоваться.
Забей. Технические детали — не главное. Не вижу никаких причин считать создание таких DLL неподъемной задачей. Тебя же не смущает тот факт, что можно встраивать свои компоненты в IDE Dalphi? Армейский норматив на реализацию такой DLL — 4 минуты. И после этого самопальные объекты прекрасным образом сериализуются и десериализуются. С точки зрения возможности никаких проблем не существует. Трудности использования неуправляемого кода относятся к разделам производительности, устойчивости, и безопасности. Не клиентам будет слишком тяжело, а сервер не рискнет гонять внутри себя код, который может вызвать проход по памяти и прочие разрушительные последствия. E>
E>В моем понимании ООБД -- это прежде всего поддержка понятия наследования по отношению к хранящимся в ней данным.
Внимание, вопрос: нафига нужно это наследование при отсутствии полиморфизма? Какой у него сценарий использования? И чем это отличается от банальной RDBMS? E>Инкапсуляция и полиморфизм -- это уже поведение, а не данные. А поведение определяется программой, которая данные использует. Но никак не данными.
С моей точки зрения, ООБД — это не столько хранилище, сколько средство создания серверов приложений. Т.е. замкнутых провайдеров определенной функциональности. Современные RDBMS вполне могут использоваться как самостоятельные app-сервера. Вот только программировать мало-мальски сложные сервера приложения с их помощью довольно-таки затруднительно. Хочется некоторого упрощения. Вот авторы ODMG сели в лужу именно благодаря тому, что декларировали, с одной стороны, наличие поведения у объектов (потому как иначе бы их никто всерьез не воспринял), а с другой стороны решили "пусть это поведение реализует кто-нибудь другой". В итоге ODMG так и остался мертворожденным. В том виде, в котором он существует, он не в состоянии конкурировать с RDBMS.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Все что было тобой написано -- правильно. Но правильно только с одной точки зрения. Просто у меня другая точка зрения.
И я считаю, что ООБД не смогли достичь значимых результатов именно потому, что на ООП есть слишком много разных точек зрения. И все они имеют право на жизнь. А некоторые -- даже жизнеспособные реализации. Здесь можно провести аналогию с ОО языками: С++, Java, C#, Smalltalk, Python и Ruby -- объектно ориентированные языки. Но они слишком разные.
Поэтому мой ответ ниже -- это не возражения на твои высказывания, а, скорее, попытка объяснить свою позицию.
E>>Ведь база данных -- это хранилище данных. Для чего там код? S>Занятный поинт
Может быть. Но я попробую его объяснить ниже.
E>> E>>Чтобы исполнятся во время выполнения запросов на серверной стороне, например. E>>Ok. Здесь это было бы полезно. Может быть. А может быть было бы достаточно в языке запросов простых примитивов сравнения. S>Гм. Простые примитивы сравнения уже есть. В RDBMS. Почему-то оказывается, что их не хватает. Если хватает, то зачем какие-то ОО в названии?
Сейчас попробую на пальцах объяснить, чем, на мой взгляд, ООБД отличаются от РСУБД.
Мне не нужно вручную разбирать объект на составляющие его атрибуты, чтобы записать его в БД. И не нужно собирать объект из разных атрибутов, чтобы прочитать. Т.е. вместо 'INSERT ...' я просто делаю (при неявной стабильности) new(db) SomeObject(...) или (при явной стабильности) db.store( new SomeObject( ... ) ).
Если операции INSERT и SELECT в РСУБД от меня скрывает какой-нибудь O/R Mapping Tool, то мне становится фиолетово, работаю ли я с ООСУБД или (O/R Mapping Tool + РСУБД). Но тут, как мне помнится, не все было ладно, т.к. O/R Mapping имел серьезные ограничения. Да и производительность такого меппинга могла в некоторых случаях проседать.
Например, на попытке сохранить в реляционной таблице атрибут объекта, который является вектором или списком (т.е. структурой данных, для которых важен порядок следования элементов). Сохранение/извлечение таких атрибутов в РСУБД является дорогой операцией по сравнению с ООСУБД.
Т.е., имхо, ООСУБД позволяет программе на ОО языке без проблем обеспечивать стабильность данных. Предоставляя при этом программе такие возможности, как защита данных, атомарные транзакции, многопользовательский режим работы и т.д. В том числе и язык запросов, хотя, имхо, при работе с объектными данными более естественным является навигационный подход.
E>>Например, если БД содержит огромное количество структурированной измерительной информации (Objectivity в CERN, как мне помниться, как раз для этого и применялась), то большинство объектов в ней вообще не нуждаются в методах. S>Как, впрочем, и в объектах. Я плохо знаком с тем, что хранит CERN. Подозреваю, что у них с теми объектами, которые мы привыкли видеть в ООП, общего мало или вообще ничего.
Я то же не знаком, но когда-то сталкивался с задачей сохранения измерительной информации в АСУТП и имитационном моделировании. Там, например, последовательность измерений для какого-то объекта могла представляться чем-то вроде:
// Один кортеж данных, снятых с одного измерительного устройства за один замер.class data_packet_t
{
protected:
std::vector< float > m_values;
...
};
// Один одномоментный замер с нескольких устройств.class measure_t
{
protected:
// Время проведения замера.
date_time_t m_when;
// Список устройств, с которых были сняты замеры и
// снятые значения.
std::map< std::string, data_packet_t > m_data;
...
};
// Результаты замеров для одного устройства.class object_measurement_session_t
{
protected :
std::list< measure_t > m_data;
...
};
S>Кстати, я встречал такое мнение, что ООБД — это "способ придания семантики данным типа BLOB".
Хороше мнение. Пожалуй, я его в чем-то разделяю.
Но есть важное отличие данных в ООБД от данных в BLOB: ООБД поддерживает эволюцию схемы данных. Например, ООБД позволит поменять тип значений в data_packet_t::m_values с float на double.
E>>Или БД, которые содержат чертежи из CAD систем. Большинство объектиков в них будут какими-нибудь точками, многоугольниками, ломанными и окружностями. S>Пардон за оффтоп, но можно мне вообще объяснить, зачем чертежи CAD систем хранить в БД? Почему не использовать более традиционное хранилище? Я еще понимаю GIS-системы: там есть и многопользовательская работа с едиными данными, и нетривиальные запросы (которые имеет смысл исполнять в клиент-серверной архитектуре). А в CAD-то зачем? Чертеж есть вроде как неделимая сущность... Там вообще на серверной стороне даже структуры вроде не надо.
На самом деле могут быть крутые CAD системы для проектирования, скажем, самолетов или автомобилей. Один чертеж может одновременно быть затребован несколькими участниками разработки одновременно -- одним для редактирования, одним для печати, третьим для оценки и т.д.
E>>Для которых поддержка методов в БД так же может быть избыточной. Для таких БД вообще поддерживать методы не имеет смысла. Но вот объектную-ориентированность они поддерживать должны -- извлеченный из БД объект должен становиться точно таким же объектом в программе, которым он был до записи в БД. S>Это не имеет никакого отношения к объектной ориентированности. Точнее, объектная ориентированность здесь не имеет отношения к базе данных. Если подходить с такой мерой, то окажется, что даже dBase поддерживает объектную-ориентированность, поскольку объект, записанный в БД, становится точно таким же объектом при чтении. Какой объект? Да тот самый, который реализует интерфейс IDataRow.
Не очень понял про IDataRow. Если объект однозначто представляется строкой таблицы, то важно, кто предоставляет IDataRow и кто отвечает за реализацию этого интерфейса объектом. Если IDataRow является частью ООСУБД (ее клиентской библиотеки) и реализация IDataRow делается не мной вручную, а инструментом ООСУБД, то мне без разницы, что под этим всем лежит dBase.
E>> E>>Или для того, чтобы закачиваться на сторону клиента вместе с объектом. То же может быть. На примере Java-апплетов что-то подобное уже изобреталось.
E>>Только может быть и другая точка зрения. У каждого клиента может быть свой интерфейс к данным. Т.е. фактически, объект SomeObject, который лежит в БД может при загрузке в одного клиента иметь совсем другой интерфейс, чем при загрузке в другого клиента. S>Именно это и есть то, чего хотелось бы избежать. Это нарушение инкапсуляции, а стало быть — неплохой способ выстрелить в ногу себе и окружающим. Объяснение чуть ниже: E>>Например, класс Point для чертежа CAD системы может иметь несколько реализаций (но одно представление данных) -- одна реализация для использования в редакторе чертежей, одна реализация для использования в программе печати чертежей, одна реализация для программы подсчета количества требуемых для реализации нарисованной на чертеже детали материалов и т.д. S>Ну, ООП в таких случаях говорит — объект обязан реализовывать несколько интерфейсов. E>> В таких условиях в централизованном хранении методов классов на сервере нет смысла. S>Только централизованная реализация этих интерфейсов позволяет гарантировать целостность объектов. Это ты конечно здорово придумал — иметь разные реализации. Ага, один клиент использует пару методов A и B. A переводит объект из одного целостного состояния (1) в другое (2) , и B этим пользуется — он точно знает, что никакого состояния 3 быть не может. А другой клиент использует метод С, который чихать на это хотел, и переводит тот же объект в состояние, непонятное для С. Поздравляем, выстрел в ногу произведен.
Не понял сарказма.
Я не говорил, что клиенты должны сами реализовывать интерфейсы объектов. Такая реализация действительно может привести к подобным проблемам, равно как и глючная централизованная реализация. Я лишь сказал, что каждый клиент имеет право пользоваться только тем интерфейсом, который ему нужен. Клиенты могут получить нужные им реализации в виде .a, .lib, .so, .dll, .jar или .zip-ов вместе с нужным им прикладным ПО. Фишка вот в чем. Допустим, есть у нас класс surface_t, который описывает поверхность какой-либо части какой-либо детали в CAD системе. В БД этот класс представляется некоторой структурой:
class surface_t
{
private :
// Материал, из которого создана поверхность.
material_t * m_material;
// Геометрическая форма поверхности.
geometry_t m_geometry;
...
};
Когда объект surface_t загружается в редактор чертежей, он должен представляться классом вот с таким интерфейсом:
class surface_t
{
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
{
public :
// Отобразить на указанном устройстве.void
draw( paint_device_t & device ) const;
...
};
Для других целей у этого объекта будут другие интерфейсы. Теперь, собственно, вопрос состоит в том, должны ли реализации всех интерфейсов объекта загружаться на машину клиента, если он загружает этот объект для какой-то специфической цели (оценки стоимости используемых материалов, например)?
Если да, то во что это может вылиться, ведь тогда с кодом методов объекта потребуется тянуть и зависимости, и зависимости зависимостей.
Если нет, то чем это отличается от того, о чем я говорил?
S>Более того, мы вынуждены доверять каждому клиенту. Представь себе банковскую систему. Никакого поведения в базе нет. Клиент вытаскивает к себе банковский счет, и оппа! у него на миллон долларов больше.
А банковский клиент стало быть должен доверять коду, который он скачивает вместе с объектом с банковского сервера?
E>>Так же, если класс объекта в БД может иметь различные реализации в коде клиентов, не понятно, какую из реализаций какого-то метода объекта использовать при выполнении запроса. Запрос от редактора чертежей -- это одно. А запрос от программы печати чертежа -- это уже совсем другое. S>Вот именно. Поэтому классу объекта в клиент-серверной БД крайне противопоказано иметь реализации на клиенте. Чтобы не было понятно, какую реализацию использовать.
Мне кажется, что в твоей фразе есть противоречие. По крайней мере я не понял о чем ты.
E>> E>>Если речь идет о неуправляемых языках, таких как ObjectPascal или C++, то хранение методов объектов в БД -- это что вообще? Наличие dll-ки рядом с БД и ее ручная подгрузка сервером БД с реализацией обращений к функциям из этой dll? E>>В некоторых случаях создание таких dll будет настолько трудоемкой задачей, что клиенты БД просто не будут этой возможностью пользоваться. S>Забей. Технические детали — не главное. Не вижу никаких причин считать создание таких DLL неподъемной задачей. Тебя же не смущает тот факт, что можно встраивать свои компоненты в IDE Dalphi? Армейский норматив на реализацию такой DLL — 4 минуты. И после этого самопальные объекты прекрасным образом сериализуются и десериализуются. С точки зрения возможности никаких проблем не существует.
Существует, если сервер на Unix-е, а клиентский код под Windows и тянет за собой множество third party библиотек.
S> Трудности использования неуправляемого кода относятся к разделам производительности, устойчивости, и безопасности. Не клиентам будет слишком тяжело, а сервер не рискнет гонять внутри себя код, который может вызвать проход по памяти и прочие разрушительные последствия.
И это тоже очень веская причина для того, чтобы для C++ объектов код на сервере не хранить.
E>>
E>>В моем понимании ООБД -- это прежде всего поддержка понятия наследования по отношению к хранящимся в ней данным. S>Внимание, вопрос: нафига нужно это наследование при отсутствии полиморфизма? Какой у него сценарий использования? И чем это отличается от банальной RDBMS?
А в RDBMS можно сделать наследование для таблиц. Т.е. сказать, что вот эта таблица является наследницей вот этой (включает в себя все существующие столбцы и еще несколько других). А затем, чтобы при изменении базовой таблице соответствующим образом автоматически были модифицированны все производные от нее таблицы.
А отличается как раз поддержкой эволюции схемы данных.
E>>Инкапсуляция и полиморфизм -- это уже поведение, а не данные. А поведение определяется программой, которая данные использует. Но никак не данными. S>С моей точки зрения, ООБД — это не столько хранилище, сколько средство создания серверов приложений. Т.е. замкнутых провайдеров определенной функциональности. Современные RDBMS вполне могут использоваться как самостоятельные app-сервера. Вот только программировать мало-мальски сложные сервера приложения с их помощью довольно-таки затруднительно. Хочется некоторого упрощения. Вот авторы ODMG сели в лужу именно благодаря тому, что декларировали, с одной стороны, наличие поведения у объектов (потому как иначе бы их никто всерьез не воспринял), а с другой стороны решили "пусть это поведение реализует кто-нибудь другой". В итоге ODMG так и остался мертворожденным. В том виде, в котором он существует, он не в состоянии конкурировать с RDBMS.
У меня другая точка зрения. Сервера приложений -- это только одно из применений ООСУБД.
Имхо, главное -- это предоставление ОО программам комфортных условий для стабилизации их объектных данных.
А причин, по которым ООСУБД сели в лужу -- множество. Ты назвал только одну из них.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BaZa, Вы писали:
BZ>Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)?
Когда-то в эпоху иерархий, некто господин Кодд сказал: "Ребята, у нас есть теория множеств. Над ней трудились огромное количество лет огромное количество математиков. Так что же мы х№№№№№№ страдаем. Давайте все хранить в реляционной базе, например MS SQL или Oracle и будем их оттуда выцеплять декларативным языком". И тут все завопили, Yes, That's good и т.д. Недолго думая соорудили проектик System R. И это оказалось настолько хорошо, что и придумать нельзя. И придумали декларативный язык для получения данных. И структура данных была гибкой. И лежали они в БД кортеж к кортежу. И язык оказался очень ассоциативным. И все подсели на это дело, не хуже чем на героин. Хорошее дело — взяли заказали данные, обработали и положили в базу.
И все бы хорошо. Но тут придумали ООП. Точнее даже не придумали, начали его развивать. И все завопили — Yes, That's good. На всех положим, а программы будем делать в ООП. Только надо что-то делать с хранилищем состояния объектов. Зачем нужно думать о данных, если мы работаем с объектами. Ну в ладошки поплевали, взяли топорик, ну и наломали дров. Создали несколько тестовых проектиков, описали то что есть и то что хотят. И все... А ведь дрова показали что не все спокойно в Багдаде. Проблем оказалось много. А сравнивать было с чем. С реляционкой. Построить ООБД легко, построить эффективную ООБД, нет. И основная проблема — ООП. В частности, то к чему стремились. А именно инкапсуляция и полиморфизм и навигация по объектам. И что получили из этого:
1. Ограничение на язык. При использовании правильной ООБД, данные инкапсулированы и не видны пользователю. В результате, объект должен быть реализован на определенном языке поддерживаемый ООБД. А языков в мире — море. Не только матерным живет мир. При сравнении с РСУБД можно работать практически на любом языке.
2. База данных для своего эффективного функционирования должна знать чем занимается тот или иной объект. И что от него требуется. А это нарушение полиформизма. Что для многих языков вообще было невозможно. В каждом, себя уважающем, РСУБД есть свой строго контролируемый язык и процесс компиляции в течении которого определяется, а что нужно делать для данной процедуры.
3. От хранилища данных требовали большей функциональности, чем от набора отношений. Если для РСУБД важен было упорядоченное чтение кортежей, то при навигационном доступе — не менее важно чтение по объектам.
ООБД — это существование многомерного мира в двухмерном мире винчестера. И ООБД — наличие двух видов доступа — навигационного и декларативного. А средства для увеличения эффективного доступа для обоих разные.
РСУБД праздновали победу. Кошельки пухли. Чистые объектники глотали слюну. Ну поскольку ООП развивался, а в кошельке, это дело такое, дна не бывает, то вопрос интеграции реляционной и объектной структуры решались. Началась (и продолжается) эпоха полумер. Эпоха полумер родила множество идей, всех и не перечислишь. Различные конструктивные меры перевода объектной структуры на этапе дизайна, ОРМ, CORBA, COM+, Java Beans, ОРСУБД, компромиссные ООБД, объекты с сериализацией и т.д. и т.п. Вплоть до эмуляции объектной структуры на РСУБД. Даже провели легимитизацию ОРСУБД с помощью громкого манифеста. Но ни одно решение, информацию о том, что объекты лежат в базе данных нас несчастных не оградило. Чистые ООБД, ушли в области где не может эффективно существовать реляционки.
Но время идет. Языки развиваются. Появились языки в которых можно контролировать выполнение. Оперативная память больше, процессоры и сети — быстрее а бизнес-логика сложнее. Одно плохо, во времена 1 манифеста девушки носили мини-юбки. А сейчас брюки. Весна блин. А вы все про компьютеры. Ладно, если начал то уж кончу. На данный момент сложилась ситуация в которой проблемы чистой ООБД могут быть решены. Просто еще произошло революции. Ублюдский ODMG убил идею. Через 15 лет, он довлеет над умами. Реляционка в плане развития выдыхается. Полумеры, типа внедрения вычислительно-полных языков, в саму РСУБД — не действуют и не эффективны. Верхи уже не могут, но и низы пока не хотят. Нужна искра. Нужна революция. Пролетарии всех стран, объединяйтесь!
Здравствуйте, eao197, Вы писали:
E>Сейчас попробую на пальцах объяснить, чем, на мой взгляд, ООБД отличаются от РСУБД.
E>Мне не нужно вручную разбирать объект на составляющие его атрибуты, чтобы записать его в БД. И не нужно собирать объект из разных атрибутов, чтобы прочитать. Т.е. вместо 'INSERT ...' я просто делаю (при неявной стабильности) new(db) SomeObject(...) или (при явной стабильности) db.store( new SomeObject( ... ) ).
Гм. Это, опять же, не имеет никакого отношения к устройству самой СУБД. С тем же успехом ты мог выполнить совершенно процедурный T-SQL:
exec CreateSomeObject @param1, @param2
Более того, в отличие от процедурных языков, где инкапсуляция была всего лишь договоренностью, то в РСУБД можно добиться инкапсуляции при помощи административных мер. Т.е. достаточно ограничить доступ к данным и заставить использовать только хранимые процедуры — и вуаля, целостность гарантирована.
E>Если операции INSERT и SELECT в РСУБД от меня скрывает какой-нибудь O/R Mapping Tool, то мне становится фиолетово, работаю ли я с ООСУБД или (O/R Mapping Tool + РСУБД). Но тут, как мне помнится, не все было ладно, т.к. O/R Mapping имел серьезные ограничения. Да и производительность такого меппинга могла в некоторых случаях проседать.
Проблема O/R маппинга ровно одна — в этом подходе код исполняется на клиенте.
E>Например, на попытке сохранить в реляционной таблице атрибут объекта, который является вектором или списком (т.е. структурой данных, для которых важен порядок следования элементов). Сохранение/извлечение таких атрибутов в РСУБД является дорогой операцией по сравнению с ООСУБД.
Очень странно. Никаких проблем с хранением таких атрибутов в РСУБД нету! Это же в чистом виде структурно-процедурное программирование. Ну где здесь объектность? Список в РСУБД можно хранить десятком способов, и никаких проблем с этим не будет. E>Т.е., имхо, ООСУБД позволяет программе на ОО языке без проблем обеспечивать стабильность данных. E>Предоставляя при этом программе такие возможности, как защита данных, атомарные транзакции, многопользовательский режим работы и т.д. В том числе и язык запросов, хотя, имхо, при работе с объектными данными более естественным является навигационный подход.
То же самое обеспечивает РСУБД. Уже. Зачем буквы ОО? E>Я то же не знаком, но когда-то сталкивался с задачей сохранения измерительной информации в АСУТП и имитационном моделировании. Там, например, последовательность измерений для какого-то объекта могла представляться чем-то вроде: E>
E>// Один кортеж данных, снятых с одного измерительного устройства за один замер.
E>class data_packet_t
E> {
E> protected:
E> std::vector< float > m_values;
E> ...
E> };
E>// Один одномоментный замер с нескольких устройств.
E>class measure_t
E> {
E> protected:
E> // Время проведения замера.
E> date_time_t m_when;
E> // Список устройств, с которых были сняты замеры и
E> // снятые значения.
E> std::map< std::string, data_packet_t > m_data;
E> ...
E> };
E>// Результаты замеров для одного устройства.
E>class object_measurement_session_t
E> {
E> protected :
E> std::list< measure_t > m_data;
E> ...
E> };
E>
Ну вот — типичный BLOB. Какие запросы должна обрабатывать СУБД? "Дай мне заданный object_measurement_session_t"? Нет проблем — сериализация + BLOB более чем достаточны. E>Хороше мнение. Пожалуй, я его в чем-то разделяю. E>Но есть важное отличие данных в ООБД от данных в BLOB: ООБД поддерживает эволюцию схемы данных. Например, ООБД позволит поменять тип значений в data_packet_t::m_values с float на double.
А, ну вот началось первое отличие тех ООБД, которые ты хочешь, от РСУБД: эволюция схемы. Действительно, BLOB одним альтером не сапгрейдишь. Впрочем, вряд ли ООБД сумеет самостоятельно сконвертировать данные в случаях, отличных от тривиальных float->double или short int -> int. Т.е. придется писать апгрейд-скрипт, точнее клиентскую программу, которая инстанцирует объекты старого класса, создаст по ним объекты нового класса, и сохранит новые объекты в СУБД. В реляционке даже проще — не будет проблем с частичными апгрейдами.
E>На самом деле могут быть крутые CAD системы для проектирования, скажем, самолетов или автомобилей. Один чертеж может одновременно быть затребован несколькими участниками разработки одновременно -- одним для редактирования, одним для печати, третьим для оценки и т.д.
Гм. И что? Ну вот у нас в таких случаях просто делается CheckOut из системы контроля версий. Суть в том, что в таком сценарии вообще не нужна структура на стороне сервера. Максимум, что надо — интеллектуальный Diff/Merge на стороне клиента, чтобы при конфликтах обновлений предотвратить потерю. Где здесь СУБД? Тут даже реляционка не нужна.
E>>>Для которых поддержка методов в БД так же может быть избыточной. Для таких БД вообще поддерживать методы не имеет смысла. Но вот объектную-ориентированность они поддерживать должны -- извлеченный из БД объект должен становиться точно таким же объектом в программе, которым он был до записи в БД. S>>Это не имеет никакого отношения к объектной ориентированности. Точнее, объектная ориентированность здесь не имеет отношения к базе данных. Если подходить с такой мерой, то окажется, что даже dBase поддерживает объектную-ориентированность, поскольку объект, записанный в БД, становится точно таким же объектом при чтении. Какой объект? Да тот самый, который реализует интерфейс IDataRow.
E>Не очень понял про IDataRow. Если объект однозначто представляется строкой таблицы, то важно, кто предоставляет IDataRow и кто отвечает за реализацию этого интерфейса объектом.
Ну как кто? ADO.NET. E>Если IDataRow является частью ООСУБД (ее клиентской библиотеки) и реализация IDataRow делается не мной вручную, а инструментом ООСУБД, то мне без разницы, что под этим всем лежит dBase.
Вот именно. А чего тебе еще надо? Все, чего ты хочешь, существует в природе уже лет пятнадцать как в наистабильнейшем виде.
E> Не понял сарказма. E>Я не говорил, что клиенты должны сами реализовывать интерфейсы объектов. Такая реализация действительно может привести к подобным проблемам, равно как и глючная централизованная реализация. Я лишь сказал, что каждый клиент имеет право пользоваться только тем интерфейсом, который ему нужен. Клиенты могут получить нужные им реализации в виде .a, .lib, .so, .dll, .jar или .zip-ов вместе с нужным им прикладным ПО. Фишка вот в чем. Допустим, есть у нас класс surface_t, который описывает поверхность какой-либо части какой-либо детали в CAD системе. В БД этот класс представляется некоторой структурой: E>Для других целей у этого объекта будут другие интерфейсы. Теперь, собственно, вопрос состоит в том, должны ли реализации всех интерфейсов объекта загружаться на машину клиента, если он загружает этот объект для какой-то специфической цели (оценки стоимости используемых материалов, например)?
Нет. Зачем вообще заморачиваться какими-то ООСУБД в данном случае? Ну вот рассмотрим до-XML формат Microsoft Word. Эти документы прекрасно живут в сети безо всяких СУБД. И клиенту не надо ничего тащить — всё, что ты называешь громким словом "интерфейс", просто вшито в соответствующую программу. Сервер не предоставляет никаких сервисов, кроме "сохранить объект" и "загрузить объект". С этим прекрасно справляется банальная сериализация. Поэтому у кого-то может стоять Word Professional, а у кого-то — WordPad. Вот тебе и разные интерфейсы.
S>>Более того, мы вынуждены доверять каждому клиенту. Представь себе банковскую систему. Никакого поведения в базе нет. Клиент вытаскивает к себе банковский счет, и оппа! у него на миллон долларов больше.
E>А банковский клиент стало быть должен доверять коду, который он скачивает вместе с объектом с банковского сервера?
Нет. Банковский клиент вообще не скачивает никакого кода. Банковский клиент выполняет запрос. Например, на перевод денег с одного счета на другой. На сервере при выполнении этого запроса задействуется вся мощь ОО и СУБД. Примерно так:
public static void TransferMoney(IAccount source, IAccount target, IAmout amount)
{
try
{
target.Balance += amount; // здесь выполняется офигенно полиморфный код, благодаря которому мы
source.Balance -= amount; // можем безболезненно вводить новые типы счетов. Так выглядит ОО в ООСУБД.
}
catch(Exception ex)
{
// при попадании в обработчик состояние всех объектов автоматически откатывается к тому, которое
// было на момент try. Так выглядят транзакции в ООСУБД.
Audit.Log("Failed to transfer {0} from {1} to {2}: {3}", amount, source, target, ex);
}
}
Все. Код, который нужен клиенту — это интерфейсный код: определения интерфейсов IAccount, IAmount, типы, используемые в запросах (public struct Amount: IAmount) и прочие тривиальные вещи. TLB.
E>Мне кажется, что в твоей фразе есть противоречие. По крайней мере я не понял о чем ты.
Нету E>И это тоже очень веская причина для того, чтобы для C++ объектов код на сервере не хранить.
Еще раз: это веская причина никогда не отпускать код объектов на клиента! Код не просто должен храниться на сервере, он должен только там и жить! СУБД, в которой часть работы исполняет клиент, уже доказали свою несостоятельность. Ну вот были раньше такие файл-серверные СУБД, в которых сервер предоставлял только доступ к хранилищу. А весь код, обрабатывающий запросы, хранился в клиенте. И взад-вперед летали странички диска, а уже "клиентская библиотека СУБД" придавала им смысл записей и таблиц. Проблемы с консистентностью и масштабируемостью похоронили эту идею для распределенных систем. Их вытеснили клиент-серверные СУБД. Ты сейчас предлагаешь сделать ту же ошибку — реализовать, фактически, архитектуру dBase IV. E>>>
E>>>В моем понимании ООБД -- это прежде всего поддержка понятия наследования по отношению к хранящимся в ней данным. S>>Внимание, вопрос: нафига нужно это наследование при отсутствии полиморфизма? Какой у него сценарий использования? И чем это отличается от банальной RDBMS?
E>А в RDBMS можно сделать наследование для таблиц. Т.е. сказать, что вот эта таблица является наследницей вот этой (включает в себя все существующие столбцы и еще несколько других). А затем, чтобы при изменении базовой таблице соответствующим образом автоматически были модифицированны все производные от нее таблицы.
Нет, так нельзя. А зачем? Я могу сделать это при помощи хранимых процедур. Один раз написать костяк типа create proc AlterRelatedTable и все.
E>У меня другая точка зрения. Сервера приложений -- это только одно из применений ООСУБД. E>Имхо, главное -- это предоставление ОО программам комфортных условий для стабилизации их объектных данных. То, о чем ты говоришь, к системам управления базами данных отношения не имеет. Стабилизация объектных данных называется persistence, и для нее существует великое множество решений. Как правило, это банальная сериализация. Встроена практически во все ОО-системы, распространенные с девяностых годов и по наше время. MFC, VCL, Java и .Net поддерживают сохранение объектов. Причем и эволюция схемы решена везде (кроме как в Delphi).
От СУБД все-таки хочется чего-то более серъезного.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Сейчас попробую на пальцах объяснить, чем, на мой взгляд, ООБД отличаются от РСУБД.
E>>Мне не нужно вручную разбирать объект на составляющие его атрибуты, чтобы записать его в БД. И не нужно собирать объект из разных атрибутов, чтобы прочитать. Т.е. вместо 'INSERT ...' я просто делаю (при неявной стабильности) new(db) SomeObject(...) или (при явной стабильности) db.store( new SomeObject( ... ) ). S>Гм. Это, опять же, не имеет никакого отношения к устройству самой СУБД. С тем же успехом ты мог выполнить совершенно процедурный T-SQL: S>
S>exec CreateSomeObject @param1, @param2
S>
А я и не говорил про устройство. Я говорил про работу с ООСУБД из моей ОО программы.
S>Более того, в отличие от процедурных языков, где инкапсуляция была всего лишь договоренностью, то в РСУБД можно добиться инкапсуляции при помощи административных мер. Т.е. достаточно ограничить доступ к данным и заставить использовать только хранимые процедуры — и вуаля, целостность гарантирована.
Целостность чего?
E>>Если операции INSERT и SELECT в РСУБД от меня скрывает какой-нибудь O/R Mapping Tool, то мне становится фиолетово, работаю ли я с ООСУБД или (O/R Mapping Tool + РСУБД). Но тут, как мне помнится, не все было ладно, т.к. O/R Mapping имел серьезные ограничения. Да и производительность такого меппинга могла в некоторых случаях проседать. S>Проблема O/R маппинга ровно одна — в этом подходе код исполняется на клиенте.
Опять не понимаю, о каком коде идет речь. О том, что метод TransferMoney исполняется на клиенте?
E>>Например, на попытке сохранить в реляционной таблице атрибут объекта, который является вектором или списком (т.е. структурой данных, для которых важен порядок следования элементов). Сохранение/извлечение таких атрибутов в РСУБД является дорогой операцией по сравнению с ООСУБД. S>Очень странно. Никаких проблем с хранением таких атрибутов в РСУБД нету! Это же в чистом виде структурно-процедурное программирование. Ну где здесь объектность? Список в РСУБД можно хранить десятком способов, и никаких проблем с этим не будет.
Объектность в том, что я, как программист, которому нужно сохранить в БД объект вида:
не задумываюсь о том, как атрибут polygon_t::m_points представляется в БД. Даже, если я работаю через O/R маппинг, я не должен об этом думать. Но если попробовать отобразить polygon_t::m_points на реляционную таблицу, то получится табличка со столбцами polygon_id (идентификатор объекта-полигона, которому принадлежит список), ordinal (порядковый номер элемента в списке), x, y. И чтобы поднять объект-полигон, нужно будет сделать два запроса -- один, чтобы поднять сам полигон и его атрибуты, второй -- чтобы выбрать все точки, которые составляют его атрибут m_points.
Именно из-за того, что сборка более-менее сложного объекта производится за счет нескольких запросов, вместо одной операции десериализации, O/R маппинг проигрывает по скорости чистым реляционным или объектным схемам.
E>>Т.е., имхо, ООСУБД позволяет программе на ОО языке без проблем обеспечивать стабильность данных. E>>Предоставляя при этом программе такие возможности, как защита данных, атомарные транзакции, многопользовательский режим работы и т.д. В том числе и язык запросов, хотя, имхо, при работе с объектными данными более естественным является навигационный подход. S>То же самое обеспечивает РСУБД. Уже. Зачем буквы ОО?
Затем, чтобы обеспечить эти характеристики хранилищам, в которых находятся именно объекты, а не таблицы. Для простоты можешь считать образами объектов обычные BLOB-ы, но это не совсем правильно.
E>>Я то же не знаком, но когда-то сталкивался с задачей сохранения измерительной информации в АСУТП и имитационном моделировании. Там, например, последовательность измерений для какого-то объекта могла представляться чем-то вроде: E>>
E>>// Один кортеж данных, снятых с одного измерительного устройства за один замер.
E>>class data_packet_t
E>> {
E>> protected:
E>> std::vector< float > m_values;
E>> ...
E>> };
E>>// Один одномоментный замер с нескольких устройств.
E>>class measure_t
E>> {
E>> protected:
E>> // Время проведения замера.
E>> date_time_t m_when;
E>> // Список устройств, с которых были сняты замеры и
E>> // снятые значения.
E>> std::map< std::string, data_packet_t > m_data;
E>> ...
E>> };
E>>// Результаты замеров для одного устройства.
E>>class object_measurement_session_t
E>> {
E>> protected :
E>> std::list< measure_t > m_data;
E>> ...
E>> };
E>>
S>Ну вот — типичный BLOB. Какие запросы должна обрабатывать СУБД? "Дай мне заданный object_measurement_session_t"? Нет проблем — сериализация + BLOB более чем достаточны.
Да, именно такие. Причем эффективно. За один запрос, вместо нескольких, как в случае с SQL.
E>>Хороше мнение. Пожалуй, я его в чем-то разделяю. E>>Но есть важное отличие данных в ООБД от данных в BLOB: ООБД поддерживает эволюцию схемы данных. Например, ООБД позволит поменять тип значений в data_packet_t::m_values с float на double. S>А, ну вот началось первое отличие тех ООБД, которые ты хочешь, от РСУБД: эволюция схемы. Действительно, BLOB одним альтером не сапгрейдишь. Впрочем, вряд ли ООБД сумеет самостоятельно сконвертировать данные в случаях, отличных от тривиальных float->double или short int -> int.
А это уже очень много. Особенно, если тип атрибута изменился в базовом классе, от которого в БД есть десяток-другой наследников.
Еще один тип операций в эволюции схемы данных -- изменение иерархии наследования. Т.е. добавление нового базового типа в иерархию или изъятие базового типа из иерархии.
S> Т.е. придется писать апгрейд-скрипт, точнее клиентскую программу, которая инстанцирует объекты старого класса, создаст по ним объекты нового класса, и сохранит новые объекты в СУБД. В реляционке даже проще — не будет проблем с частичными апгрейдами.
Да, в случае нетривиальных изменений такое придется делать.
E>>На самом деле могут быть крутые CAD системы для проектирования, скажем, самолетов или автомобилей. Один чертеж может одновременно быть затребован несколькими участниками разработки одновременно -- одним для редактирования, одним для печати, третьим для оценки и т.д. S>Гм. И что? Ну вот у нас в таких случаях просто делается CheckOut из системы контроля версий. Суть в том, что в таком сценарии вообще не нужна структура на стороне сервера. Максимум, что надо — интеллектуальный Diff/Merge на стороне клиента, чтобы при конфликтах обновлений предотвратить потерю. Где здесь СУБД? Тут даже реляционка не нужна.
Не скажи. Задачи бывают разные. Например, мне довелось участвовать в разработке системы конструирования АСУТП, где все данные находились в ООБД. Было очень удобно при многопользовательской работе. Один разработчик добавляет новый объект в БД, начинает его конструировать, а второй в этот момент может делать ссылки на новый объект и включать его в собственные объекты.
И тут появляется еще один момент, про который я забыл сказать -- контроль целостности ссылок. ООСУБД обязана это поддерживать. Причем контроль целостности может проявляться в двух вещах:
— запрет на уничтожение объекта, если на него есть ссылки;
— автоматическая корректировка ссылок на удаляемый из БД объект.
E>>>>Для которых поддержка методов в БД так же может быть избыточной. Для таких БД вообще поддерживать методы не имеет смысла. Но вот объектную-ориентированность они поддерживать должны -- извлеченный из БД объект должен становиться точно таким же объектом в программе, которым он был до записи в БД. S>>>Это не имеет никакого отношения к объектной ориентированности. Точнее, объектная ориентированность здесь не имеет отношения к базе данных. Если подходить с такой мерой, то окажется, что даже dBase поддерживает объектную-ориентированность, поскольку объект, записанный в БД, становится точно таким же объектом при чтении. Какой объект? Да тот самый, который реализует интерфейс IDataRow.
E>>Не очень понял про IDataRow. Если объект однозначто представляется строкой таблицы, то важно, кто предоставляет IDataRow и кто отвечает за реализацию этого интерфейса объектом. S>Ну как кто? ADO.NET.
Ты думаешь, что ADO.NET осчастливит весь мир, и кроме ADO.NET больше ничего не может быть?
E>>Если IDataRow является частью ООСУБД (ее клиентской библиотеки) и реализация IDataRow делается не мной вручную, а инструментом ООСУБД, то мне без разницы, что под этим всем лежит dBase. S>Вот именно. А чего тебе еще надо? Все, чего ты хочешь, существует в природе уже лет пятнадцать как в наистабильнейшем виде.
Так чего же все время что-то еще изобретают?
Видно, не все, что нужно есть.
E>> Не понял сарказма. E>>Я не говорил, что клиенты должны сами реализовывать интерфейсы объектов. Такая реализация действительно может привести к подобным проблемам, равно как и глючная централизованная реализация. Я лишь сказал, что каждый клиент имеет право пользоваться только тем интерфейсом, который ему нужен. Клиенты могут получить нужные им реализации в виде .a, .lib, .so, .dll, .jar или .zip-ов вместе с нужным им прикладным ПО. Фишка вот в чем. Допустим, есть у нас класс surface_t, который описывает поверхность какой-либо части какой-либо детали в CAD системе. В БД этот класс представляется некоторой структурой: E>>Для других целей у этого объекта будут другие интерфейсы. Теперь, собственно, вопрос состоит в том, должны ли реализации всех интерфейсов объекта загружаться на машину клиента, если он загружает этот объект для какой-то специфической цели (оценки стоимости используемых материалов, например)? S>Нет. Зачем вообще заморачиваться какими-то ООСУБД в данном случае? Ну вот рассмотрим до-XML формат Microsoft Word. Эти документы прекрасно живут в сети безо всяких СУБД. И клиенту не надо ничего тащить — всё, что ты называешь громким словом "интерфейс", просто вшито в соответствующую программу. Сервер не предоставляет никаких сервисов, кроме "сохранить объект" и "загрузить объект". С этим прекрасно справляется банальная сериализация. Поэтому у кого-то может стоять Word Professional, а у кого-то — WordPad. Вот тебе и разные интерфейсы.
Да, именно об этом я и говорил. Но, сериализация на клиенте может быть и банальная, да только на сервере к ней добавляются:
— защита от сбоев;
— многопользовательский режим работы;
— поддержка транзакций и блокировок;
— поддержка ссылочной целостности;
— поддержка эволюции схемы данных;
— поддержка поисковых запросов.
Да, можно все это сделать за счет сериализации+РСУБД в качестве хранилища+еще что-то для контроля ссылочной целостности и эволюции схемы данных. Только, боюсь, эффективность такого решения будет не очень высокой. Да и сложность надстройки над РСУБД может быть сравнима со сложностью самой ООСУБД.
S>>>Более того, мы вынуждены доверять каждому клиенту. Представь себе банковскую систему. Никакого поведения в базе нет. Клиент вытаскивает к себе банковский счет, и оппа! у него на миллон долларов больше.
E>>А банковский клиент стало быть должен доверять коду, который он скачивает вместе с объектом с банковского сервера? S>Нет. Банковский клиент вообще не скачивает никакого кода. Банковский клиент выполняет запрос. Например, на перевод денег с одного счета на другой. На сервере при выполнении этого запроса задействуется вся мощь ОО и СУБД. Примерно так: S>
S>public static void TransferMoney(IAccount source, IAccount target, IAmout amount)
S>{
S> try
S> {
S> target.Balance += amount; // здесь выполняется офигенно полиморфный код, благодаря которому мы
S> source.Balance -= amount; // можем безболезненно вводить новые типы счетов. Так выглядит ОО в ООСУБД.
S> }
S> catch(Exception ex)
S> {
S> // при попадании в обработчик состояние всех объектов автоматически откатывается к тому, которое
S> // было на момент try. Так выглядят транзакции в ООСУБД.
S> Audit.Log("Failed to transfer {0} from {1} to {2}: {3}", amount, source, target, ex);
S> }
S>}
S>
S>Все. Код, который нужен клиенту — это интерфейсный код: определения интерфейсов IAccount, IAmount, типы, используемые в запросах (public struct Amount: IAmount) и прочие тривиальные вещи. TLB.
Т.е. твой посыл состоит в том, чтобы ООСУБД отвечала за бизнес-логику.
А зачем? Чем существующие решения в виде серверов приложений не удовлетворяют?
Что в этом случае будет означать ОО в ООСУБД?
E>>Мне кажется, что в твоей фразе есть противоречие. По крайней мере я не понял о чем ты. S>Нету E>>И это тоже очень веская причина для того, чтобы для C++ объектов код на сервере не хранить. S>Еще раз: это веская причина никогда не отпускать код объектов на клиента! Код не просто должен храниться на сервере, он должен только там и жить! СУБД, в которой часть работы исполняет клиент, уже доказали свою несостоятельность. Ну вот были раньше такие файл-серверные СУБД, в которых сервер предоставлял только доступ к хранилищу. А весь код, обрабатывающий запросы, хранился в клиенте. И взад-вперед летали странички диска, а уже "клиентская библиотека СУБД" придавала им смысл записей и таблиц. Проблемы с консистентностью и масштабируемостью похоронили эту идею для распределенных систем. Их вытеснили клиент-серверные СУБД. Ты сейчас предлагаешь сделать ту же ошибку — реализовать, фактически, архитектуру dBase IV.
Вообще-то я ничего не предлагал. Я просто высказал свое отношение к хранению методов объектов в СУБД.
Кроме того, я вообще считаю, что развитый язык запросов в ООСУБД нужен далеко не для всех задач. Во многих случаях, с которыми я сам сталкивался, нужна была всего одна операция -- найти ссылку на объект по некоторому ключу. Далее по найденой ссылке объект извлекался из БД и весь остальной доступ осуществлялся через навигацию по ссылкам.
Да, признаю, я работал с ООСУБД в очень специфических областях. И мои взгляды на то, как должны работать ООСУБД будут отличаться от твоих. Но я продолжаю настаивать на мнении, что нельзя сделать общую, универсальную ООСУБД. В принципе.
E>>>>В моем понимании ООБД -- это прежде всего поддержка понятия наследования по отношению к хранящимся в ней данным. S>>>Внимание, вопрос: нафига нужно это наследование при отсутствии полиморфизма? Какой у него сценарий использования? И чем это отличается от банальной RDBMS?
E>>А в RDBMS можно сделать наследование для таблиц. Т.е. сказать, что вот эта таблица является наследницей вот этой (включает в себя все существующие столбцы и еще несколько других). А затем, чтобы при изменении базовой таблице соответствующим образом автоматически были модифицированны все производные от нее таблицы. S>Нет, так нельзя. А зачем? Я могу сделать это при помощи хранимых процедур. Один раз написать костяк типа create proc AlterRelatedTable и все.
Так вот в ООСУБД этого вообще делать не нужно.
E>>У меня другая точка зрения. Сервера приложений -- это только одно из применений ООСУБД. E>>Имхо, главное -- это предоставление ОО программам комфортных условий для стабилизации их объектных данных. S> То, о чем ты говоришь, к системам управления базами данных отношения не имеет. Стабилизация объектных данных называется persistence, и для нее существует великое множество решений. Как правило, это банальная сериализация. Встроена практически во все ОО-системы, распространенные с девяностых годов и по наше время. MFC, VCL, Java и .Net поддерживают сохранение объектов. Причем и эволюция схемы решена везде (кроме как в Delphi).
S>От СУБД все-таки хочется чего-то более серъезного.
А ты добавь к сериализации еще и остальные характеристики СУБД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Т.е. твой посыл состоит в том, чтобы ООСУБД отвечала за бизнес-логику. E>А зачем? Чем существующие решения в виде серверов приложений не удовлетворяют?
Да тем, что сейчас писать сервера приложений уж очень тяжело. E>Что в этом случае будет означать ОО в ООСУБД?
Как обычно — поддержку наследования, инкапсуляции и полиморфизма. Именно этого сейчас в RDBMS нет. E>Вообще-то я ничего не предлагал. Я просто высказал свое отношение к хранению методов объектов в СУБД.
Именно. Ты предлагаешь хранить код методов на клиенте. В таком случае все действия можно выполнять только в клиенте, а СУБД всего лишь отдает сырые данные и принимает сырые данные. Темное средневековье. E>Да, признаю, я работал с ООСУБД в очень специфических областях. И мои взгляды на то, как должны работать ООСУБД будут отличаться от твоих. Но я продолжаю настаивать на мнении, что нельзя сделать общую, универсальную ООСУБД. В принципе. S>>От СУБД все-таки хочется чего-то более серъезного. E>А ты добавь к сериализации еще и остальные характеристики СУБД.
Я-то как раз не против. Вот только добавление "остальных" характеристик СУБД с неизбежностью приводит к необходимости замкнуть реализацию, т.е. хранить и исполнять код только на стороне сервера.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Т.е. твой посыл состоит в том, чтобы ООСУБД отвечала за бизнес-логику. E>>А зачем? Чем существующие решения в виде серверов приложений не удовлетворяют? S>Да тем, что сейчас писать сервера приложений уж очень тяжело.
Сервера приложений? Или приложения, которые работают под управлением серверов приложений?
E>>Что в этом случае будет означать ОО в ООСУБД? S>Как обычно — поддержку наследования, инкапсуляции и полиморфизма. Именно этого сейчас в RDBMS нет.
Но при этом код сосредотачивается на сервере.
E>>Вообще-то я ничего не предлагал. Я просто высказал свое отношение к хранению методов объектов в СУБД. S>Именно. Ты предлагаешь хранить код методов на клиенте. В таком случае все действия можно выполнять только в клиенте, а СУБД всего лишь отдает сырые данные и принимает сырые данные. Темное средневековье.
Может быть. Только и таких реализаций open-source не так уж и много. А коммерческие дороги.
E>>Да, признаю, я работал с ООСУБД в очень специфических областях. И мои взгляды на то, как должны работать ООСУБД будут отличаться от твоих. Но я продолжаю настаивать на мнении, что нельзя сделать общую, универсальную ООСУБД. В принципе. S>>>От СУБД все-таки хочется чего-то более серъезного. E>>А ты добавь к сериализации еще и остальные характеристики СУБД. S>Я-то как раз не против. Вот только добавление "остальных" характеристик СУБД с неизбежностью приводит к необходимости замкнуть реализацию, т.е. хранить и исполнять код только на стороне сервера.
Да, я понял твою позицию.
Имхо, это достижимо только для управляемых языков.
Т.е. C++ идет лесом, а это мне не нравиться
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>Сервера приложений? Или приложения, которые работают под управлением серверов приложений?
Конечно же собственно серверные приложения. Не важно, под чем они работают. Вся фишка в том, что современная наука никак не помогает писать мало-мальски нетривиальные серверные приложения. Например, реализация банального SMTP-релея представляет собой headache. Даже если использовать RDBMS в качестве storage. Авиабилеты до сих пор приходится продавать через терминальные сервера, как и тридцать лет назад! Написать нормальный сервис продажи авиабилетов пока никому не удалось (насколько мне известно).
E>Но при этом код сосредотачивается на сервере.
Естественно.
E>Может быть. Только и таких реализаций open-source не так уж и много. А коммерческие дороги.
Так их немного именно потому, что нафиг они не упали.
E>Имхо, это достижимо только для управляемых языков.
Насколько я вижу — да. Требования стабильности, безопасности, и производительности не удается удовлетворить другим способом. E>Т.е. C++ идет лесом, а это мне не нравиться
Почему же? С++/CLI вполне подойдет.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Сервера приложений? Или приложения, которые работают под управлением серверов приложений? S>Конечно же собственно серверные приложения. Не важно, под чем они работают. Вся фишка в том, что современная наука никак не помогает писать мало-мальски нетривиальные серверные приложения. Например, реализация банального SMTP-релея представляет собой headache. Даже если использовать RDBMS в качестве storage. Авиабилеты до сих пор приходится продавать через терминальные сервера, как и тридцать лет назад! Написать нормальный сервис продажи авиабилетов пока никому не удалось (насколько мне известно).
Понятно. Но ты, как я понимаю, больше в сторону .Net смотришь? А в Java, имхо, в этом направлении активно копают.
E>>Может быть. Только и таких реализаций open-source не так уж и много. А коммерческие дороги. S>Так их немного именно потому, что нафиг они не упали.
E>>Имхо, это достижимо только для управляемых языков. S>Насколько я вижу — да. Требования стабильности, безопасности, и производительности не удается удовлетворить другим способом.
Вот это то и плохо.
Хотя, даже если код на стороне сервера будет управляемым, то проблемы производительности у СУБД будут все равно. Да и с маштабируемостью, возможно, то же.
E>>Т.е. C++ идет лесом, а это мне не нравиться S>Почему же? С++/CLI вполне подойдет.
С++/CLI пусть идет еще более темным лесом!
Лично у меня нет никакого желания с ним связываться.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Sinclair пишет:
> E>Сервера приложений? Или приложения, которые работают под управлением > серверов приложений? > Конечно же собственно серверные приложения. Не важно, под чем они > работают. Вся фишка в том, что современная наука никак не помогает > писать мало-мальски нетривиальные серверные приложения. Например, > реализация банального SMTP-релея представляет собой headache.
Из-за дьявольски сложного семейства почтовых стандартов. Можешь еще
CORBA 3 вспомнить, которую
в полном объеме вообще никто не реализует.
> Даже если использовать RDBMS в качестве storage.
В SMTP-релее как раз хранилище не особо важно. Там и обычной FS хватает.
> Авиабилеты до сих пор приходится продавать через терминальные сервера, > как и тридцать лет назад! Написать нормальный сервис продажи > авиабилетов пока никому не удалось (насколько мне известно).
Плохо, значит, известно. Те же ЖД билеты у нас уже через сравнительно
нормальную систему продают. Да и ничего в таких системах сверхсложного
нет — максимум десятки простых запросов в секунду.
Cyberax пишет: >> Конечно же собственно серверные приложения. Не важно, под чем они >> работают. Вся фишка в том, что современная наука никак не помогает >> писать мало-мальски нетривиальные серверные приложения. Например, >> реализация банального SMTP-релея представляет собой headache. > > Из-за дьявольски сложного семейства почтовых стандартов. Можешь еще
Десяток команд SMTP — где там сложность?
> CORBA 3 вспомнить, которую > в полном объеме вообще никто не реализует. > >> Даже если использовать RDBMS в качестве storage. > > В SMTP-релее как раз хранилище не особо важно. Там и обычной FS хватает. > >> Авиабилеты до сих пор приходится продавать через терминальные сервера, >> как и тридцать лет назад! Написать нормальный сервис продажи >> авиабилетов пока никому не удалось (насколько мне известно). > > Плохо, значит, известно. Те же ЖД билеты у нас уже через сравнительно > нормальную систему продают. Да и ничего в таких системах сверхсложного > нет — максимум десятки простых запросов в секунду.
подозреваю, что раз не могли написать, значит ставилась задача срубить
бабла, а не создать некую систему.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Andrei N.Sobchuck пишет:
>>> Конечно же собственно серверные приложения. Не важно, под чем они >>> работают. Вся фишка в том, что современная наука никак не помогает >>> писать мало-мальски нетривиальные серверные приложения. Например, >>> реализация банального SMTP-релея представляет собой headache. >> Из-за дьявольски сложного семейства почтовых стандартов. Можешь еще > Десяток команд SMTP — где там сложность?
В разборе писем, разборе адресов (никто не пользуется UUCP, а в
стандарте-то он остался), роутинге, резольвинге имен и т.д.
Известный факт: больше всего стандартов RFC именно о email.
Не понял сарказма.
То, о чем ты говоришь, к системам управления базами данных отношения не имеет. Стабилизация объектных данных называется persistence, и для нее существует великое множество решений. Как правило, это банальная сериализация. Встроена практически во все ОО-системы, распространенные с девяностых годов и по наше время. MFC, VCL, Java и .Net поддерживают сохранение объектов. Причем и эволюция схемы решена везде (кроме как в Delphi).
