funikovyuri авторЯ не против )) Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен. В этом случае тезис превосходства РМД над ОМД в плане adhoc становится более слабым.

adhoc нужен чтобы эти самые SP написать и при этом не менять схему БД. А инкапсуляция - она только изолирует разные части системы друг от друга и к произвольным запросам отношения не имеет

Если мы говорим про SP то это уже не adhoc!!!! SP пишутся программерами!
Один раз! В принципиальном отношении по сравнению с декларативным программированием в SP нет ничего качественно нового.

vadiminfo
Т.е. Вы думаете, что признаком РМД является отсутствие на клиенте SQL?

Где я такое писал? )) Я писал что признаком ненужности adhoc является отсутствие на клиенте SQL запросов а-ля SELECT|INSERT|UPDATE

vadiminfo
Одним из основным достоинстоинств РМД и заключается независмость от клиентского приложения и наоборот, именно от того, что МД а БД.
Однако присутствие на клиенте вообще, возможности выполнять SQL в интерактивном режиме осталась. При это не всегда и нужно на нем выполнять SQL.

Вот и я говорю - не всегда нужно. ч.т.д. УРА! )))

vadiminfo
Но в ООСУБД он не нужен? Вы уверены?

Я уверен что для ООСУБД adhoc полезен и нужен. Тезис заключается в другом. В мире РБД наметилась тенденция в отказе от adhoc.

funikovyuri shuklin

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

В таком случае, этот тезис качественно не отличается от "произвольный алгоритм обхода графа - это не значит, что его пользователи будут писать - это значит, лишь, что имея схему графа ООБД можно написать алгоритм обхода этого графа (никто не запрещает при этом использовать OQL или XPath), о котором не знали разработчики схемы этого графа. Ну само собой, этот алгоритм можно написать на C# и скомпилить в DLL".

PS. Устоявшегося термина "схема графа" имхо еще нет. Я бы предпочел - паттерн нейронного ансамбля (в случае СНС).

SarinБудущее ОРСУБД и ООСУБД
Расскажите.

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

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

PS. На данный момент я разрабатываю СООБЗ Cerebrum. Текущую версию можно скачать по адресу http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx . Если кто то имеет какието проблемы, коментарии или пожелания по поводу моей разработки - большая просьба сообщать мне об этом любым удобным способом.

женщина-программисткаКак вы думаете, является ли поддержка целостности данных ключевой функцией субд, и если нет, то для чего предназначена такая субд?

Я думаю, что отсутствие такой поддержки значительно сокращает область возможного применения СУБД. Тем не менее Cerebrum на данный момент не имеет никаких автоматических средств по поддержке целостности данных. Это забота программиста. В будущем такие средства могут быть реализованы на более высоких уровнях. На уровне VNPI реализация данной возможности маловероятна. Дело в том, что в Cerebrum несколько разных экземпляров объектов могут иметь один и тот же OID. Поэтому в общем случае может быть невозможно определить тот handle space в котором должен находится PK для текущего значения - таких handle space может быть несколько. Дальше, в системе ООБД (надстройка над VNPI) поддерживается создание отсутствующих аттрибутов (объектов) on demand. Поэтому отсутствие объекта с некоторым OID не является причиной в отказе создания ссылки с этим OID.

Я уже писал, что Cerebrum преднозначен в первую очередь для моделирования нейронных сетей, семантических сетей, активных семантических сетей, иерархических семантических сетей и сетей фреймов. В узлах этих сетей можно разместить экземпляры собственных классов реализованные на языке C#.

На данный момент, в качестве примера применения СООБЗ Cerebrum разработана продукционная экспертная система. Я предполагаю, что такую ООБД можно использовать в различных CAD|CAM приложениях.

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

Здесь возникает первое отличие от РБД - нет разницы между оперативкой и БД. Чтобы обеспечить отмену сохранения необходимо разработать развитую систему версионинга объектов. Этот этап как раз в процессе. Поэтому я считаю что Cerebrum не поддерживает транзакций (несмотря на то что можно пнуть метод Rollback у объекта NativeDomain и отменить все последние изменения).

Структура у объекта разумеется есть. Все объекты рекомендуется хранить в разобранном на скаляры виде. Поддерживаются деревья объектов. Объект может содержать аттрибуты, являющиеся сложными объектами, у которых тоже есть аттрибуты-объекты ... на любую глубину (до 2млрд простых объектов на одну бд).

женщина-программисткаСУБД должна уметь гарантировать их целостность. Если, например, Cerebrum этого не умеет и у нее нет мат модели для этого, зачем тогда ее сравнивать с РСУБД.

Уже не раз здесь писал что уровень VNPI представляет собой граф с раскрашенными однонаправленными связями.

женщина-программистка[Я уже писал, что Cerebrum предназначена в первую очередь для моделирования нейронных сетей]
Это предметная область, но интересно, что она хранит для такого класса задач? Содержимое объектов, живущих сейчас, или blob-поля, или то и другое?

И то и другое - по желанию программиста, реализующего объект.
У объекта могут быть аттрибуты. Аттрибуты могут быть: объектами, скалярными значениями, коллекциями OID. Если аттрибут объекта является объектом, то у него тоже могут быть аттрибуты вышеперечисленных типов.

Целостность данных в пределах одного дерева поддерживается автоматически. Целостность FOREIGN KEY между разными ветками деревьев должна обеспечиваться прикладным программистом. Учитывая что основым достоинством ООБД является прямая навигация между разными объектами, то опять же мой старый тезис, что в данной версии целостность не поддерживается остается в силе. Так как можно создать объект в аттрибуте которого будет находится OID несуществующего объекта.

vybegalloИ наследование, и полиморфизм есть у Информикса начиная с 9 версии, год примерно 1997. Только оказалось, что никому оно нахрен не надо - это я тебе, голуба, говорю как бывший работник ихнего саппорта.
У них наследование таблиц или настоящих объектов? Если настоящих (ни чем не хуже объектов С++) то имхо отдел рекламы у Информикса хреновый. В С++ всем оно надо... а если добавить еще и персистентность - то уже не надо. Так получается? А вот если таблиц, или чегото таблице-подобного, тогда да. Толку от такого наследования, если всеравно второй объект придется на C++ ваять и custom serialization в него делать. И автоматизация этого дела не поможет. Методы то объектов-сервера так и останутся в объекте на сервере, а приложение будет работать с клоном объекта на клиенте. Врядли они сделалют маршаллинг вызовов прокси сервеного объекта (аналог Remoting в .NET) Единственный выход - полноценный ОО язык программирования на стороне сервера. .NET предоставляет фраймеворк для таких языков, Cerebrum предоставляет среду для persistent объектов. Кстати, если кому очень надо, можно Cerebrum под Remoting в клиент-серверном сценарии запускать, но это уже достоинство Microsoft .NET

vubegalloнаследование таблиц, естественно. Поскольку в БД ценность представляют именно Д в чистом виде, а не Д с присохшей к ним бумаж.. оберткой в виде методов С++/C#/Java/ObjectPascal/Perl 5/... и (каждый язык - со своей версией). То, что вы хотите, называется object persistence framework - их последнее время расплодилось дофига, некоторые по отзывам весьма неплохи, (Hibernate). Но с точки зрения разработчика хранилища данных - ему объекты даром не нужны, его интересуют всякие кубы и adhoc запросы.

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

vybegalloКстати, как вы себе представляете хранение объектов С++ на сервере ? Ладно там Java и C# с псевдокодом, но что случится с объектами С++ если вы, не дай бог, задумаете мигрировать с NT 32bit на AIX 64bit ? А код, написанный под десяток юниксов, видеть не доводилось ? там ifdef на ifdef-e сидит и defin-ом погоняет... не, пока не придуман (и стандартизован наподобие SQL) язык описания объектов - это все несерьезно.

В очень многих задачах не нужно никуда мигрировать. Windows forever , Unix must die )))))

c127 shuklin
Здесь возникает первое отличие от РБД - нет разницы между оперативкой и БД.


Где Вы ухитряетесь вычитывать такие перлы? Или сами придумываете? ОСНОВНОЕ ПОЛОЖЕНИЕ РСУБД это абстрагирование от способа храниения данных, с этого все начиналось, т.е. система должна скрывать (и все современные СКЛ сервера это успешно делают) от программиста где физически и каким образом лежат данные, т.е. разницы между оперативкой и БД нет и быть не может, иначе это не РСУБД.

Тьфу на того, кто скажет, что Cerebrum это РСУБД ))) Ващето я это ухитрился сделать а не вычитать. Готовое решение для Microsoft .NET Framework 1.1 доступно в исходниках по адресу http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx

Только не говорите мне, что РСУБД абстрагируют данные от их хранения в памяти приложения. В приложении данные по прежнему храняться в экземплярах классов. А вот ОБД стирает грань между БД и памятью ПРИЛОЖЕНИЯ.