Кто сталкивался, поделитесь впечатлениями.

Может объектно-ориентирванные?

Они самые. Так расскажет кто-нибудь?

ОО БД и причины их создания

Статья не впечатлила - обо всем и ни о чем, так рассуждения об "объектности", я сам не работал с объектными технологиями баз данных и хотелось бы услышать не рассуждения и "объективные исторические предпосылки возникновения объектных технологий" (вся статья смахивает на лекцию какого-то отраслевого техникума народного хозяйства по программированию), а примеры, архитектуру и логику работы, плюсы и минусы технологии... Может кто-то другого мнения об этой статье, но я ничего для себя из нее не вынес, и могу написать подобную статью по любому языку или технологии включая те которых я и в глаза не видывал - достаточно прочитать какое-нибудь ревью, и размазать на 5-10 килобайт текста.

Согласен с Vit. Хотелось бы увидеть мнение людей, которые потрогали эту технологию руками.

Я не оцениваю статью. Но на фирме мы используем примерно такой же подход. Правда в основу положили Microsoft SQL сервер и на него накладываем объектную модель.Почему MSSQL, а не Cache или какую-нибудь другую действительно ОO? Большинство заказчиков ориентировано на MSSQL. В основном выйгрыш  при  проявляется при проектировании БД( пока у нас все новые задача логически легко впихивается в выбранную концепцию) а также при программировании.Вот еще один пример, где пошли по такому же пути
http://www.ivn.newmail.ru/index_rus.html Смотреть матриал по Ultima-S

Правтически я этим не занимаюсь - только теоретически Поэтому могу дать несколько ссылок, которые могут быть полезными
http://www.inteltec.ru/publish/articles/objtech/4kx4_9.shtml
http://www.tts.tomsk.su/personal/~sas/DBMS/96_4/source/36.htm
http://www.ccas.ru/~prz/hp1.html - несколько статей по теме
http://y-larin.chat.ru/russian/oodbms/dbms_index.htm - несколько статей по теме
Можно так же поискать литературу по ключевым словам на сайтах www.osp.ru и www.citforum.ru - там ее очень много.

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

По поводу предлагаемой выше статьи - я не могу ее воспринимать серьезно.

Реляционные базы данных недостаточно точно описывают окрущающий мир. При их помощи можно создавать двумерные сечения, связанные между собою. Набор же реальных объектов, как правило, в такую схему не укладывается. Во-первых, объекты могут обладать _разным_ набором свойств. Во-вторых, не все свойства объектов могут быть известны. В-третьих, не всегда объекты одного класса четко связаны с объектами другого класса. В-четвертых, атрибуты объектов сами могут быть объектами или коллекциями. И наконец, объектная схема имеет свойство меняться по ходу эксплуатации системы. А соответствующее изменение структуры таблиц - это отдельная  и достаточно геморройная задача, так как SQL запросы совершенно не толерантны к таким изменениям. Приходится много чего переписывать. Все это снижает эффективность базы и создает трудности в проектировании. Дополнительный отрицательный момент в реляционных базах - добавление еще одной среды, с которой должен иметь дело программист. Если он и до этого должен был соорудить правильно работающую систему из PHP, XML, XSLT, генерящих HTML, CSS, Javascript и работу с DOM, добавление ко всему этому хозяйству еще и PL/SQL надежности коду отнюдь не прибавляет.

Поэтому возникла идея хранить объекты именно в виде объектов. Отдельных объектов.  каждый - со своими свойствами. И изменить способы обращения к ним. Один из вариантов реализации такого подхода - Persistent Objects. Наборы классов, связанных с хранилищем. Когда программист создает объект, наследованный от такого класса, в хранилище создается его копия. Вся работа с базой скрыта в недрах служебного класса, и программист не думает об этом вообще. Ничего не нужно сохранять, все сохраняется само и при следующем запуске программы ты можешь достать свои объекты из хранилища и продолжить работу с ними. Единственно, о чем надо озаботиться дополнительно - о создании некоторых объектов-коллекций, позволяющих выбирать объекты по признакам. При наличии таких коллекций, связанных с хранилищем, оно определяет принадлежность каждого пихаемого объекта к ним и ставит у себя соответствующие галочки, так что потом можно быстро выбрать нужные объекты. Это аналог индексов в SQL базах.

Есть и другие подходы. Например, хранить объекты в XML форме. И не только.

Сумбурно, но надеюсь, понятно.

Как бы это объяснить....:) Требовать от реляционных баз данных, что бы они служили для описания окружающего мира не следует. Реляционная модель описывает ДАННЫЕ - и ни на что большее она не претендует. Сравнивать отношения и обьекты так же  неразумно, как сравнивать , скажем, устройство оперативной памяти и архитектуру объектной программы. Перое описывает систему ХРАНЕНИЯ данных (мы можем сказать это про любую Рел. БД),   а второе позволяет ПРЕДСТАВИТЬ эти данные в удобном для человека виде (в виде объектов).

Вооот....:)

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

   Представления идентифицируемых сложных объектов в реляционной базе данных

и

Модель "объект - качество".

К сожалению - это только теория. Даже протипа нет, а могла бы классная штука получиться.

Цитата

Как бы это объяснить....:) Требовать от реляционных баз данных, что бы они служили для описания окружающего мира не следует. Реляционная модель описывает ДАННЫЕ - и ни на что большее она не претендует.

Фигушки, именно требует. Ведь ЧТО ЕСТЬ ДАННЫЕ?

Прочитал статейки. Ну и бардак, надо сказать! Я человек простой и практически неграмотный, так что первую статейку по диагонали прочитал, но выводы неверны: все, что там в конце написано, давным-давно реализовано. Этих библиотек уже, просто как собак нерезанных. Начиная от Cache и кончая поделками Вась Пупкиных на SourceForge. Я когда попытался обзор сделать, нашел штук пятнадцать подобных систем и понял, что дальше искать не буду. Так что бери и пользуйся. На C++ и Java.

По поводу второй статейки. Не люблю я этих "Доид принадлежит П от ля-ля-ля при ву-аля от тру-ля-ля до тра-ля-ля", и все это в тройных скобках. Поэтому изложу все то же самое, но попроще.

Тут следует фрагмент доки, писанной для одного заказчика. Дока из Ворда, так что картинка - условно.
------------------------------------------------------------
Как мы описываем мир? Мы говорим фразы типа: «Вес стола равен двадцати килограммам». Принято считать это описанием одного из свойств объекта стол. Вот у нас есть стол и у него есть свойство вес, равное числу двадцать. Но к чему тогда относится слово «килограммы»? Оно относится к весу, это единица измерения веса. Значит, свойство вес имеет свойство измеряться в килограммах. А поскольку то, что имеет свойства, является объектом, мы можем и должны рассматривать сущность «Вес» тоже как объект. Отсюда следует, что свойство есть направленное соотношение между двумя объектами. Причем, несмотря на направленность конкретной связи, мы не можем дифференцировать объекты по этому признаку, так как один и тот же объект может являться одновременно объектом-источником для одного свойства и объектом-целью для другого, как объект «Вес» в рассматриваемом примере. Изобразим информацию, передаваемую примером, графически:

Код

20           Килограммы Стол -------> Вес --------------> Единицы измерения

Жирной рамкой тут изображены объекты, надписанными стрелками – связи между ними, они же значения свойств объектов. Можно читать это так: килограмм есть единица измерения веса, двадцать есть вес стола.
-------------------------------------------------------------

Что из этого проистекает:

1. Всё есть недифференцированные объекты.
2. Свойство - троично. Оно есть отношение чего-то к чему-то и имеет какое-то значение.

Что я и реализовал.

Упрощенный вариант: есть таблица объектов, где есть ID, Имя и ParentID (это мы их параллельно кубу в дерево выстраиваем). И есть таблица свойств, где есть ObjectID, TargetID и Value. Эта таблица позволяет нам сделать многомерный разреженный куб. Вуаля!

Ну, на самом деле немного сложнее. Например, таблиц свойств столько, сколько типов свойств ты используешь, для эффективного индексирования. Использовал ты CHAR(12) - у тебя появилась таблица l_CHAR_12_, где все такие свойства и лежат. Ну, еще таймстэмпы есть у всех объектов и свойств (для репликации) и так далее.

Но смысл остается тот же. Реляционная база используется как основа, на ней можешь навешать любую схему. Любой объект может соотноситься с любым объектом, иметь любые свойства. Работаешь с этим хозяйством типа $oo->createObj('\\Города\\Псков'); или $oo->setProp($Town, '\\common\\properties\\distance',$distance);
(это PHP).
Правда, выбирать непосредственно трудно, поэтому пришлось язычок написать, и транслятор к нему. Даешь OQL - получаешь SQL.
Получилось достаточно удобно, типа $recordset=$shop->executeOQL('SELECT parcels.*,parcels->\\shop\\parms\\products\\price as Price FROM \\shop\\orders\\%\\% as parcels ORDER BY parcels.Name');

Тут есть ветка \shop\orders, в ней лежит куча заказов, из каждого заказа растут посылки, вот они-то и выбираются с их ценами. Сначала все это транслируется в соответствующий SQL [SELECT parcels.*, lnk0.Value AS Price FROM o as o0,o as o1,o as parcels LEFT JOIN l_FLOAT AS lnk0 ON lnk0.FID=parcels.ID AND lnk0.TID=80 WHERE (o0.ParentID=25 AND o0.Name LIKE "orders" AND o1.ParentID=o0.ID AND parcels.ParentID=o1.ID) ORDER BY parcels.Name], а потом выполняется.

Так что и тут, как видишь, у кого - теория, а у кого - и практика.

О чем спорим то?

Еще раз повторю - реляционная модель служит для описания ДАННЫХ, поэтому требовать от РБД адекватности в описания моделируемой ПРЕДМЕТНОЙ ОБЛАСТИ не следует в принципе. Это не мое мнение. По этому поводу могу порекомендовать статью Абстракции и модели в системах баз данных. и далее по ссылкам. Она тоже требует тщательного прочтения. Но это Вам не грозит.

Почему я так говорю?

Во-первых, Вы сами признались.

Во-вторых, в своей первой статье я вовсе не претендую на пальму первенства в области разработки (даже речи об этом нет). Цель статьи совсем другая - показать бессмысленность спора "объектные системы проит реляционных". Я пытаюсь показать, что реляционный подход к ХРАНЕНИЮ данных может не противоречит объектному подходу к их ПРЕДСТАВЛЕНИЮ и реляционная модель может описывать данные реализующие схему данных основанную на объектных принципах (разницу между понятиями "модель данных" и "схема данных" хорошо объесняется по приведенной ссылке). О чем спорим, спрашиваю? Цитата из предыдущего поста - "Реляционная база используется как основа, на ней можешь навешать любую схему."

В-третьих, для того, что бы излагать что-то "попроще" надо это, как минимум, внимательно прочитать. Это я о "попроще" изложнении своей второй статьи.В ней я начинаю с того, что пытаюсь показать, что объектная концепция НЕ является достаточной для адекватного описания окружающего мира. По моему мнению НЕ ВСЕ моделируемые сущности могут описываться как объекты. Я пытаюсь дать критерий для различия объектов и "необъектов". Критерий очень простой: если для сравнения сущностей используется ее ЯВНО ЗАДАННОЕ значение, то это "необъект" (я называю это качество). Если же для того, что бы отличить одну сущность от другой требуется дополнительная идентификация, то это объект. Например "вес" - это не объект, для его сравнения мы используем только его явно заданное значение (20). Тот факт, что Вы вводите единицу измерения (кг) ничего не меняет, просто явно заданное значнение становиться сложным и включает явно заданные единицы измерения (20,"кг"). Стол же - это объект, поскольку могут существовать стола с одни и тем же весом, цветом, размерами.... т.е. столы не могут однозначено сравниваться только исходя из явно заданных значений. Почему я делаю упор на ЯВНО ЗАДАННЫХ значениях? Да потому что именно явно заданные значения являются единсвенно возможным способом представления данных в реляционной модели - т.е. "необъекты"(качества) должны описываться в терминах именно реляционной модели.  Далее я эту тему развиваю.

Ну и что? как ваше изложение соотноститься с этим? Да никак -  я говорю о другом! Хотя бы потому, я буквально на первой странице говорю, что не имеет смысла описывать сущность "вес", как объект, я Вы это делаете... То есть Вы  попросту вводите в заблуждение читателей отностительно моей статьи, потому что вы не удосужились внимательно прочитать ее. Нахрена так делать?

Несколько практических вопросов о  системе, созданной Вами. Заметьте, что я спрашиваю именно про систему хранения... про серверную компоненту (что бы было понятнее). Независима ли она от использующей ее программы? Существет ли язык, описывающий ее и служащий для ее управления? Храняться ли в ней метаданные (я имею в виду хотя бы описание структуры хранимых сложных объектов)? Можно ли получить и изменить метаданные? Контролирует ли система то, что вносимые данные соответсвуют этим метаданным? Контролирует ли система то, что при изменении метаданных существующие данные не будут противоречить внесенным изменениям? Реализует ли система хранения метаданных наследование и полиморфизм? Реализует ли система хранения метаданных хранение методов? Возможно ли выполнение эти методов (на стороне сервере, конечно)? Если на эти вопросы Вы ответите утвердительно, то совершенно очевидно, что Ваша работа заслуживает самого пристального внимания.

Наконец, насчет теории и практики. Хорощей практики без теории не бывает. Хотя бы потому, что теория дает однозначные практические ответы (взять хотя бы реляционные БД, основанные на математически строгой теории). К сожалению, в области  систем хранения данных сейчас наблюдается разброд и шатание, связанное не в последнюю очередь с тем, что множество крутых программёров забивают на теорию. Я уверен, что люди въехавший в теорию рел.БД, не будет создавать "постреляционные" базы данных (это такое же бредовое выражение, как и "постлогические") или утверждать, что рел. БД плохо описывают окружающий мир. А кто не въехал, тот по прежнему будет ваять "язычки" и "библиотечки", что с одной стороны в общем-то помогает самоутверждению как крутейшего программёра с правом подчеркивания сего момента и виртуального похлопывания по плечам, но с другой стороны приводит к возникновению программных монстров, страшных как тришкин кафтан.

Ни в коем случае не хочу, что бы последний абзац был отнесено на чей то личный счет

Хе. Кажись парни с DelphiKindom подвалили.  

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

Oracle -это ОО язык как делфи
у него все свое.
Вот это крутой язык 5 лет с ним
Советую, не пожалеешь
Это и есть база данных, одна из самых крутых на сегоднешний день

Цитата(adminlion @ 21.7.2002, 04:17)

Oracle -это ОО язык как делфи у него все свое. Вот это крутой язык 5 лет с ним Советую, не пожалеешь Это и есть база данных, одна из самых крутых на сегоднешний день

Еслиб только он не был такой дорогой!