Привет, Всем!

Меня интересует, какие задачи сообщество считает более эффективно решать на основе ООСУБД по сравнению с реляционными ?

Я думаю, что на таких ООСУБД эффективнее решать те задачи, которые в своем естественном виде имеют ярко выраженные сетевые модели.

Например можно вcпомнить моделирование нейронных сетей или разработку CAD.

С уважением, Дмитрий.

guest_20040621> Офисные информационные системы
> Интерактивные и динамическик Web - узлы.

Откуда Вы это взяли, позвольте поинтересоваться?

При работе с распределенными информационными системами, лично у меня возникло впечатление, что ООБД более приспособлены к решению бухгалтерских задач, чем стандартные реляционки. Был проект, в котором по ТЗ изменения в постановке вносились в систему каждые 3 месяца. При этом на внесение изменений отводилось всего 3 дня. Этого удалось добится реализовав на основе SQL таблиц модель данных документа. Пришлось отказаться от 3NF. Вобщем то что пошло в эксплуатацию, после пары лет экспериментов, более походит на сетевую БД реализованную на основе РМД, а не на чистую РМД. Поэтому я уверен, что замена РМД на ООМД оправдана даже в некоторых задачах, считающихся классикой для применения РМД. А обосновано это тем, что в реальном мире реальные сущности не организованы в ортогональные таблицы. Модель реального мира более естественно ложиться на модель иерархических активных семантических сетей.

c127А эти задачи вообще всегда при решении единственным средством вызывают значительные трудности. Интересно увидеть ООБД, например, которая сама отрисует GUI на клиенте, или вдруг станет компилировать программное обеспечение.

В СООБЗ Cerebrum http://contest2005.gotdotnet.ru/Request/Apps/Other/168720.aspx
модель GUI описывается объектами находящимися в ООБД. При этом объекты, которые находятся на стороне БД получают и обрабатывают запросы GUI. Так что посмотреть можно уже сегодня )))

vadiminfoНа таких задачах недостатки РСУБД проявляются, как правило, минимально
а достоинста существенно.
Конечно, если Вы на клиппере или досовском парадоксе лабали, возможно всякое.
Попробуйте Оракл. Рекомендую. Конечно, проектировать нужно хоть не много уметь. Но зато потом - легкая прогулка.

Пасиба, как раз его пробовали )) Тот жизненный опыт, о котором я вспомнил, включал 35 серверов Oracle распределенных по 35 обласным центрам Украины + 4 ЦБД в Киеве. Врочем они сейчас, без моего участия, выполняют ранее поставленные задачи и все так же успевают в течении нескольких дней адаптироваться к изменяющемуся каждые 3 месяца законодательству Украины.

vadiminfoКстати, именно это обстоятельство являлось причиной сомнений, что ООСУБД сможет захватить весь рынок без дополнительных каких-то достижений.
А если она претендует быть постреляционной, то должна захватить не менее 90%.

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

С уважением, Дмитрий.

Привет!

funikovyuri shuklin
может хоть вы на мой вопрос ответите?
funikovyuriДалее, ОО модель данных (в терминах, например, UML) это классы, атрибуты и отношения. Так вот - не могли бы вы привести пример оо-модели которую бы нельзя или сложно было отобразить на реляционную? А то ваши соратники по оосубд, в приведенном вами топике, ссылались на отсутствие наследования в РБД - что говорит против их знаний в области проектирования РБД, но никак не против РБД как таковых.


Попробую ответить.

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

Итак, чтобы продемонстрировать достоинства ООБД надо найти задачу, модель предметной области является сетью и / или требует наследования и полиморфизма. (Кстати версант не может продемонстрировать такие преимущества, так как они сами и признались, методы у объектов в БД не поддерживаются, тогда одного из удобнейших возможностей ОО - полиморфизма в FastObjects нет, мне странно, как можно не поддерживать полиморфизм в .NET Возможно Алексей что то напутал или недообъяснил и полиморфизм таки есть )

В качестве такой задачи можно предложить например векторный графический редактор типа Visio. Все графические объекты, которые потребуется хранить в БД, можно унаследовать от общего класса Widget. На прямую навигацию в ООБД естественным образом ложатся связи между графическими объектами.

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

Итак, как мы знаем, все объекты в ООБД имеют свой уникальный ID по которому их можно быстро найти - это аналог PK c индексом. Само его наличие не дает преимуществ перед РБД. Однако возможность нарушать 1NF - хранить в одном атрибуте объекта список значений из этих ID позволяет реализовывать коллекции объектов использующих метод прямой навигации (что в РБД уже затруднительно, так как отношения один ко многими или составной ключ - это уже не один а несколько операций поиска по индексам, к тому же прямая навигация в таком случае ИМХО удобнее JOIN ).

Теперь упрощенная модель классов из наймспайс Cerebrum.Reflection

public class MemberDescriptor : Cerebrum.Integrator.GenericComponent
{
public string Name
public string DisplayName
public string Description
}

Названия пропертей говорят за себя Это базовый класс для описателей которые обладают свойсвами имя, дружественное имя и описание. Многие объекты могут иметь такие атрибуты, поэтому удобно наследовать такие объекты от MemberDescriptor.



public class AttributeDescriptor : MemberDescriptor
{
public Cerebrum.Runtime.NativeHandle AttributeTypeHandle
public System.Type AttributeType
public Cerebrum.Runtime.IConnector GetTypeDescriptor()
}
Дескриптор атрибута – описывает имя некоторого атрибута объекта. Он расширяет объект MemberDescriptor добавляя свойства AttributeType, AttributeTypeHandle а также метод GetTypeDescriptor()

AttributeType возвращает тип данного атрибута.
GetTypeDescriptor() возвращает объект-дескриптор этого же типа.

Например, для свойства Name объекта MemberDescriptor В ООБД создаются экземпляр объекта AttributeDescriptor с значениями свойств соответсвенно

Name = “Name”
DisplayName = “Name”
Description = “Object name”
AttributeType = typeof(System.String)
GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String

Таким образом экземпляры класса AttributeDescriptor описывают свойства объектов, хранимых в ООБД, в том числе и свойства собственно класса AttributeDescriptor


public class TypeDescriptor : MemberDescriptor
{
public string QualifiedTypeName
public Cerebrum.Runtime.KernelObjectClass KernelObjectClass
public System.Type ComponentType
}

Описывает тип объекта.

Свойство QualifiedTypeName содержит строковое полное имя .NET объекта, например “System.String”

Свойство KernelObjectClass рассматривать не будем.

Свойство ComponentType возвращает typeof(QualifiedTypeName) тоесть .NET тип описываемый дескриптором

Свойства, унаследованные от MemberDescriptor тривиальны.


Для свойства QualifiedTypeName создается экземпляр AttributeDescriptor у которого
Name = “QualifiedTypeName”
DisplayName = “Qualified Type Name”
Description = “.NET Qualified Type Name”
AttributeType = typeof(System.String)
GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String

Итак мы имеем несколько классов экземпляры которых описывают объекты, содержащиеся в ООБД и сами кстати (экземпляры) так же являются объектами находящимися в ООБД. Поэтому они описывают сами себя.

Можно заметить, что у объектов имеются совместимые атрибуты – например у многих объектов есть атрибут “Name” который описывает имя объекта. Объекты являющиеся экземплярами одного и того же класса имеют одинаковый список атрибутов.

Логично сгруппировать однотипные объекты в таблицы у которых колонки будут представлять атрибуты, а строки – собственно экземпляры объектов.

public class TableDescriptor : MemberDescriptor, System.ComponentModel.IListSource
{
public Cerebrum.Runtime.NativeVector GetSelectedAttributesVector()
public Cerebrum.Runtime.NativeVector GetSelectedComponentsVector()
public System.Type ComponentType
public Cerebrum.Data.TableView DefaultView
}
Описывает таблицу из экземпляров объектов. Свойства унаследованные от MemberDescriptor соответсвенно описывают имя, дружественное имя и описание данной таблицы.

Метод GetSelectedAttributesVector возвращает коллекцию атрибутов - колонок таблицы, этому методу соответсвует экземпляр AttributeDescriptor у которого
Name = “SelectedAttributes”
DisplayName = “SelectedAttributes”
Description = “SelectedAttributes collection”
AttributeType = typeof(System.ComponentModel.IBindingList)

Метод GetSelectedComponentsVector возвращает коллекцию объектов - строк таблицы, этому методу соответсвует экземпляр AttributeDescriptor у которого
Name = “SelectedComponents”
DisplayName = “SelectedComponents”
Description = “SelectedComponents collection”
AttributeType = typeof(System.ComponentModel.IBindingList)

Все экземпляры AttributeDescriptor перечислинны в таблице TableDescriptor.Name = “Attributes”
Все экземпляры TypeDescriptor перечислинны в таблице TableDescriptor.Name = “Types”
Все экземпляры TableDescriptor перечислинны в таблице TableDescriptor.Name = “Tables”

При этом экземпляры класса AttributeDescriptor.Name = “Name” разумеется содержаться в коллекции строк таблицы Attributes а так же в коллекциях атрибутов (колонок) таблиц “Attributes”, “Types” и “Tables”

Экземпляр класса TableDescriptor.Name = “Tables” хранится в своей же коллекции строк таблицы (SelectedComponents)

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

Данным примером мы продемонстрировали что на основе ООБД возможна эмуляция РБД.

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


С уважением, Дмитирй.

PS.

shuklinеще один пример, уже разработанный и внедренный в СООБЗ Cerebrum - БД конфигурации.

Данный пример доступен в исходных текстах как часть реализации СООБЗ Cerebrum (но не ЭС Elex - тоесть другой zip тянуть)

guest_20040621
А почему Вы решили, что информационная система = бухгалтерские задачи?

А почему знак равно? Бухгалтерские системы - частный случай информационных.

guest_20040621
> Был проект,

То есть Вы считаете, что далеко идущие выводы можно делать на основании одного проекта? ;)

Конечно можно. Даже один проект может определить новый класс проектов. Пусть у этого класса и не будет много экземпляров. Все рвано это уже класс .
А по классу проектов выводы делать можно.

guest_20040621
> Этого удалось добится реализовав на основе SQL таблиц модель данных
> документа. Пришлось отказаться от 3NF.

Хм... что Вы имеете в виду под "моделью данных документа", поясните, пожалуйста.

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

guest_20040621
И почему пришлось отказаться от 3НФ?

Слишком большая была стоимость владения у предыдущих версий в связи с ограниченностью возможностей.

guest_20040621
Ну, на что это походит, зависит исключительно от направления взгляда наблюдающего. ;) В итоге все равно СУБД - реляционная, правда? ;)) Какого цвета на ней рюшечки - дело десятое.

Однако вовсе не десятое дело, какова модель предметной области, обрабатываемая этим СУБД. Если модель сетевая, то возникают накладные расходы на эмуляцию сети в таблицах РМД.

guest_20040621
Ну, я тоже много в чем уверен. Аргументы есть? Сравнение совокупной стоимости владения, например. Или любая другая объективная оценка?

От предыдущих версий пришлось отказаться ))
И далее
guest_20040621
> А обосновано это тем, что в реальном мире реальные сущности не
> организованы в ортогональные таблицы.

Позвольте поинтересоваться, что следует из этого наблюдения? И как это связано с недостатками [неудобством применения? неприспособленностью для решения задачи?] реляционных баз данных (вообще, было бы неплохо хотя бы перечислить, какими именно недостатками)? И с преимуществами нереляционных СУБД, естественно?
Приходится моделировать сети на основе РМД. А это приводит к дополнительным расходом. Сначала работаем с РМД как с РМД, затем переводим все в сеть и работаем уже как с сетью (куда деватся то если предметная область - сеть).

guest_20040621
Хм... ровно то же другими словами: кто-то забил гвоздь микроскопом, у него получилось, - значит, теперь считаем микроскоп инструментом для забивания гвоздей. Цитата: "Может, в консерватории что-то подправить?" ;)


Забивание гвоздей микроскопами - тоже класс задач. Возможно разработать оптимальные приемы забивания гвоздей микроскопом, разработать гвозди предназначеннче для забивания микроскопами ... ; ))) Если это экономически где то оправдано, почему нет?

guest_20040621
Вы просто не умеете их готовить. Абслютно стандартные проблемы со стандартными методами решений.

А кто спорит, только истинные святые великой веры в РМД способны правильно готовить документы. В этом абсолютно никто не сомневается )))

Для не обращенного в святую веру очень не помешает перечень ссылочек с кошерными методами по готовке документов.

guest_20040621
Ну да, возникают. И не только на эмуляцию сети. И что в этом криминального? Я получаю гибкое, переносимое, легко управляемое, стандартное решение. В обмен на небольшую избыточность. Меня это абсолютно устраивает. В чем проблема-то?

Криминального - ничего. А если устраивает - то и вовсе чудно. А вот многих РМД не устраивает. И решения на их основе, тоже не устраивают. Меня к примеру.

c127Ну где я сказал модель? Не "модель", а "отрисовывать". Модель и обработку запросов от ГУЯ я и в РСУБД нарисую без проблем.

OnClick реализуете в РСУБД ? Речь идет о обработке совбсвенно события и реализации всего полезного (в том числе и отрисовки) в объекте лежащем в СООБЗ. Чтайте мысли автора а не то что вам хотелось бы прочесть вместо них - будет легче понимать чужие идеи )))

c127Извиняйте, коллега, но СКЛ язык не полный, там нет рекурсии, в нем чего угодно (эквивалентное машине Поста) не напишете.

А эта мелочь в данном контексте не существенна, т.к. проблема заключалась в представимости сети средсвами SQL.

А рекурсию можно эмулировать организовав стек в какойто таблице. И ваще в данном контектсе стоит рассматривать SQL в расширенном контексте вместе с SP, триггерами и пр.

mvПо-моему, ООСУБД годятся для чего угодно....

Абсолютно и полностью согласен со всеми тезисами. Чтобы их воплотить в жизнь - нада работать )) Движемся потихоньку.

с127Нельзя получить последовательность натуральных чисел заранее неизвестной длины.


К слову. С точки зрения чистых теоретиков, эта задача не решаема обычным компом в принципе (Хотя абстрактной машиной Тьюринга - решаема). См. докозательство Клини. (Идея - как представить число с размерами битового образа превышающими суммарный объем RAM & HD ?)

guest_20040621Только зачем это Вам, если Вы уже выбрали другое решение? ;)


Действительно, проверили ряд решений, выбрали, реализовали, внедрили, завершили внедрение уже как 2 года назад, теперь из чисто ностальгических соображений иногда со старыми знакомыми пивко потягиваем )) Вроде не жалуются )))

с127На всякий случай: Вашу диссертацию я вчера прочитал, может не сильно внимательно, этих определений там не нашел, возможно пропустил, поэтому если на нее ссылаетесь то ссылайтесь поподробнее, с указанием страницы или подраздела.

Определений объекта и других ООП понятий в диссере нет вовсе - диссер нейронкам посвящен. Проблема построения базы знаний в диссере затронута краем, четких определений из области БЗ там тоже нет. В качестве книжки на ночь рекомендую японский пятитомник по ИИ. Он как раз проблеме знаний посвящен.

Alexey RovdoВ ООСУБД Versant коды методов не хранятся в самой БД - они являются частью кода приложения, которое с этой базой работает.

Что мне не ясно. Я помню, что ты говорил, что методы не поддерживаются. Однако, что мешает мне реализовать в классе, хранящемся в БД FastObjects какой нибудь абстрактный интерфейс? Что произойдет если вызвать метод такого интерфейса? Во всех примерах которые ты приводил (из тех что я видел) ни ни методов ни темболее интерфейсов в классах, живущих в БД не наблюдалось. Мне непонятно как можно запретить наследование интерфейсов являющееся частью .NET Framework и что будет если такое реализовать и попытаться запустить? Об этом я и писал.

Alexey Rovdoне к каждому объекту индивидуально, как в вашей системе.

А про чужую разработку фантазировать не надо )) Я вот очень пытаюсь не зная деталей реализации БД от версант ничего к ним своего не прифантазировать )))

В моей системе реализация методов объектов находится в обычной .NET сборке лежащей в файловой системе рядом с БД. Только данные экземпляра хранятся в БД. А описание метаданных и реализация методов - обеспечивается средой .NET

Павел ВоронцовА другие операции в СУБД и не нужны. Всё остальное к логике хранения, манипулирования и целостности данных отношения не имеет.

Если для решения ваших задач такие операции не нужны, это не значит, что они не нужны и для решения всех остальных задач.