Ищутся материалы по %subj%.

Пока интересуют общие вопросы, обзорные статьи и т.п.
Т.е. уже не "это такие штучки, которые вам позволяют представлять..." (т.е. для полных ламеров), но и не глобально-углубленные научные труды.

Дело в том, что требуется создать нечто, очень по своим принципам похожее на ООБД и не хочется инветить байсикл

Гуглю, естественно, интенсивно, но, может, кто поделится из личных запасов.

Spaider -> "Объектно-ориентированные БД: основные принципы, организация," :

S> Ищутся материалы по %subj%.

S> Пока интересуют общие вопросы, обзорные статьи и т.п.
S> Т.е. уже не "это такие штучки, которые вам позволяют представлять..."
S> (т.е. для полных ламеров), но и не глобально-углубленные научные
S> труды.

S> Дело в том, что требуется создать нечто, очень по своим принципам
S> похожее на ООБД и не хочется инветить байсикл

S> Гуглю, естественно, интенсивно, но, может, кто поделится из личных
S> запасов.

Ага. Ты есть тот амбициозный руководитель проекта по созданию ООБД!

Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Пошло все на.... ]

Здравствуйте, hrg, Вы писали:

hrg>Ага. Ты есть тот амбициозный руководитель проекта по созданию ООБД!

Амбиций у меня хватает, но про какого руководителя ты говоришь, я не понимаю.

Spaider -> "Re[2]: Объектно-ориентированные БД: основные принципы, орган" :

S> Здравствуйте, hrg, Вы писали:

hrg>> Ага. Ты есть тот амбициозный руководитель проекта по созданию
hrg>> ООБД!

S> Амбиций у меня хватает, но про какого руководителя ты говоришь, я не
S> понимаю.

Требуется амбициозный руководитель<br />
проекта по разработке Объектной СУБД.

Автор: serkin
Дата: 17.07.04

Yury Kopyl aka hrg | http://id.totem.ru |
"Хоббиты-маздай! Мордовия-фарева!" (С)Сарумян

Здравствуйте, Spaider, Вы писали:

S>Ищутся материалы по %subj%.

1. Мне кажеться, что лучший способ --- попробовать! Меня тоже в свое время заинтересовали вопросы построения ООБД (в плане самообразования). Я ограничился тем, что скачал Cache' и документацию к нему с их сайта. Чем сразу вызвал большую заинтересованость их филиала в Москве. Меня забросали документацией, советами о том, как лучше начинатьвнедрять Cache' на больших проектах, периодически интересуются, не угас ли мой пыл. Ограничился я лишь написанием небольшой демки, которая работала с Cache' через COM. Но впечатления, в том числе и от работы группы поддержки, остались только положительные.

2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно. Один из способов описан в статье Анатолия Тенцера "Бд &mdash; хранилище объектов". Второй способ принят у нас --- для базовых классов, допускающих наследование вводится поле --- ID класса. Кстати, примерно такой же способ применяется и в Cache'.

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

Здравствуйте, hrg, Вы писали:

hrg>Spaider -> "Re[2]: Объектно-ориентированные БД: основные принципы, орган" :

S>> Здравствуйте, hrg, Вы писали:

hrg>>> Ага. Ты есть тот амбициозный руководитель проекта по созданию
hrg>>> ООБД!

S>> Амбиций у меня хватает, но про какого руководителя ты говоришь, я не
S>> понимаю.

hrg>Требуется амбициозный руководитель<br />
<span class='lineQuote level1'>hrg&gt;проекта по разработке Объектной СУБД.</span>

Автор: serkin
Дата: 17.07.04

А, нет
Это не про меня Я вообще Москву и москвичей не очень-то люблю. Живу в Минске.
Какая жалость, что мой вопрос высплыл после вышеупомянутой хрени. Не то время, не то место

Да и проект мой не является в чистом виде ООБД. Просто в процесее обдумывания модели данных накрыло: "так вот что это такое, вот куда копать-то надо...."

Здравствуйте, Mystic, Вы писали:

M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно. Один из способов описан в статье Анатолия Тенцера "Бд &mdash; хранилище объектов".

А можно ссылку поточнее

Здравствуйте, Spaider, Вы писали:

S>Ищутся материалы по %subj%.

Посмотри:
http://www.osp.ru/dbms/1996/01/46.htm
http://www.osp.ru/os/1999/03/08.htm

Вообще, в свое время, в журналах "Открытые системы" и "СУБД" эта тема часто освещалась. На сайте www.osp.ru через поиск еще и другие статьи найти можно.

Здравствуйте, Spaider, Вы писали:

S>Ищутся материалы по %subj%.

S>Пока интересуют общие вопросы, обзорные статьи и т.п.
S>Т.е. уже не "это такие штучки, которые вам позволяют представлять..." (т.е. для полных ламеров), но и не глобально-углубленные научные труды.

S>Дело в том, что требуется создать нечто, очень по своим принципам похожее на ООБД и не хочется инветить байсикл

S>Гуглю, естественно, интенсивно, но, может, кто поделится из личных запасов.

Гугл оно конечно, хорошо. Но будте осторожны:

В области объектно-ориентированных баз данных на протяжении последних нескольких лет наблюдается поразительное затишье, которое одни склонны воспринимать как упадок технологии, а другие — как переход технологии в зрелое и устойчивое состояние. По моим наблюдениям, подобное затишье временами ведет к возникновению заблуждений и даже мифов у людей, близких к ИТ, но не являющихся специалистами в области баз данных. Одно из таких заблуждений состоит в том, что человек принимает сложившийся у него в голове набор терминов (объект, атрибут, метод, класс, наследование и т.д.) за общепризнанную объектно-ориентированную модель данных.

Сергей Кузнецов, Открытые Системы

Вот краткая ретроспектива темы, от самого начала до конца.

Основополагающая статья. С этого начинаем:
М. Аткинсон и др., «Манифест систем объектно-ориентированных баз данных», // СУБД, № 4, 1995. http://www.osp.ru/dbms/1995/04/23.htm

Этим продолжаем:
Л.А. Калиниченко, «Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния». // СУБД, № 1, 1996. http://www.osp.ru/dbms/1996/01/46.htm

Далее читаем это:
Арк Андреев, Дмитрий Березкин, Роман Самарев, «Внутренний мир объектно-ориентированных СУБД». // Открытые системы, № 3, 2001. http://www.osp.ru/os/2001/03/047.htm

А потом вот это, о "перспективах отрасли" и месте в ней ООБД:
С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests.

Ну и, естественно, смотрим на всякие Жасмины и Каше, или про что еще в этих статьях узнаете.

Mystic -> "Re: Объектно-ориентированные БД: основные принципы, организа" :

M> объектов[/url]". Второй способ принят у нас --- для базовых классов,
M> допускающих наследование вводится поле --- ID класса. Кстати,
M> примерно такой же способ применяется и в Cache'.

Т.е. наследники и базовый класс в одной таблице?

Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас

Здравствуйте, Spaider, Вы писали:

S>А можно ссылку поточнее

http://www.podgoretsky.com/cgi-bin/dlcounter/npscnt?file=http://podgoretsky.com/ftp/Docs/Delphi/Tenser/6.zip&amp;file_id=Tenser6

Здравствуйте, hrg, Вы писали:

hrg>Т.е. наследники и базовый класс в одной таблице?

Примерно вот так:

CREATE TABLE TBL_OBEJECT
(
  ID NUMBER(20) NOT NULL,
  XOBJECT_ID NUMBER(20)
);

ALTER TABLE TBL_OBEJECT ADD CONSTRAINT PK_OBJECT PRIMARY KEY(ID);

CREATE TABLE TBL_LIST -- Наследуется от OBJECT
(
  ID NUMBER(20) NOT NULL,
  NAME VARCHAR2(32)
);

ALTER TABLE TBL_OBEJECT ADD CONSTRAINT PK_LIST PRIMARY KEY(ID);

ALTER TABLE TBL_OBEJECT ADD CONSTRAINT FK_LIST_ID
  FOREIGN KEY(ID) REFERENCES TBL_OBJECT ON DELETE CASCADE;

CREATE TABLE TBL_LIST_ITEM -- Наследуется от OBJECT
(
  ID NUMBER(20) NOT NULL,
  PARENT_ID NUMBER(20) NOT NULL,
  DISPLAY_NAME VARCHAR2(32)
);

ALTER TABLE TBL_LIST_ITEM ADD CONSTRAINT PK_LIST PRIMARY KEY(ID);

ALTER TABLE TBL_LIST_ITEM ADD CONSTRAINT FK_LIST_ITEM_ID
  FOREIGN KEY(ID) REFERENCES TBL_OBJECT ON DELETE CASCADE;

ALTER TABLE TBL_LIST_ITEM ADD CONSTRAINT FK_LIST_ITEM_PARENT_ID
  FOREIGN KEY(PARENT_ID) REFERENCES TBL_LIST;

CREATE TABLE TBL_COMPLEXOBJ -- Наследует от LIST и LIST_ITEM
(
  ID NUMBER(20) NOT NULL,
  SOME_DATA ...
);

ALTER TABLE TBL_COMPLEXOBJ ADD CONSTRAINT PK_LIST PRIMARY KEY(ID);

ALTER TABLE TBL_COMPLEXOBJ ADD CONSTRAINT FK_COMPLEXOBJ_ID_LIST
  FOREIGN KEY(ID) REFERENCES TBL_LIST ON DELETE CASCADE;

ALTER TABLE TBL_COMPLEXOBJ ADD CONSTRAINT FK_COMPLEXOBJ_ID_LIST_ITEM
  FOREIGN KEY(ID) REFERENCES TBL_LIST_ITEM ON DELETE CASCADE;

Mystic -> "Re[3]: Объектно-ориентированные БД: основные принципы, орган" :

M> Здравствуйте, hrg, Вы писали:

hrg>> Т.е. наследники и базовый класс в одной таблице?

M> Примерно вот так:

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

Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...

Здравствуйте, hrg, Вы писали:

hrg>Ага. Наследование с таблицей для каждого класса. А как потом осбираете
hrg>значения атрибутов по разным полям? Это же куча запросов чтобы создать один
hrg>объект?

Зачем куча? Обычные джойны.

А как насчет объектно-реляционного отображения? По-моему, все объектные БД на сегодняшний день являются сырыми, впрочем, как и OQL. Имхо, ORM — это хорошее решение проблемы.

Здравствуйте, Mystic, Вы писали:


M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно.
Не хочу быть догматичным, но по моему это очень страшно. Такое не может называться OODB. В реляционной структуре нет месту одному из главных плюсов ООDB, а именно прямому доступу к объекту.

С уважением, Gleb.

GlebZ пишет:

> M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так
> это и страшно.
> Не хочу быть догматичным, но по моему это очень страшно. Такое не
> может называться OODB. В реляционной структуре нет месту одному из
> главных плюсов ООDB, а именно прямому доступу к объекту.
>
То есть? OR-mapping позволяет представить объект как набор записей в БД
(и наоборот).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>То есть? OR-mapping позволяет представить объект как набор записей в БД
C>(и наоборот).

Абсолютно точно. Это действительно называется OR-mapping. ООDB — не является OR-mapping, именно в термине BD. То есть, это должно быть отдельное хранилище данных. И во вторых, ООDB, кроме того, что может хранить оптимизированно не записи а именно объекты, может обеспечивать прямой доступ к состоянию этих объектов (по OID). В ORM и соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно тормознее. Поэтому утверждается что ООБД со сложными типами данных работает быстрее.

С уважением, Gleb.

GlebZ пишет:

> C>То есть? OR-mapping позволяет представить объект как набор записей в БД
> C>(и наоборот).
> Абсолютно точно. Это действительно называется OR-mapping. ООDB — не
> является OR-mapping, именно в термине BD. То есть, это должно быть
> отдельное хранилище данных. И во вторых, ООDB, кроме того, что может
> хранить оптимизированно не записи а именно объекты, может обеспечивать
> прямой доступ к состоянию этих объектов (по OID). В ORM и
> соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно
> тормознее. Поэтому утверждается что ООБД со сложными типами данных
> работает быстрее.

Далеко не факт, так как доступ к рядам в таблице RDB тоже может
производиться по быстрому идентификатору ряда, если он известен
(например, если взят из отношения). То есть при желании RDB будет
работать так же быстро, хотя для этого уже нужен нестандартный SQL.

Гораздо интереснее посмотреть другие фичи ODB, например, GC для
персистентных объектов. Потом еще интереснее посмотреть как они
реализованы в существующих продуктах, и сделать соответствующие выводы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>GlebZ пишет:

>> C>То есть? OR-mapping позволяет представить объект как набор записей в БД
>> C>(и наоборот).
>> Абсолютно точно. Это действительно называется OR-mapping. ООDB — не
>> является OR-mapping, именно в термине BD. То есть, это должно быть
>> отдельное хранилище данных. И во вторых, ООDB, кроме того, что может
>> хранить оптимизированно не записи а именно объекты, может обеспечивать
>> прямой доступ к состоянию этих объектов (по OID). В ORM и
>> соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно
>> тормознее. Поэтому утверждается что ООБД со сложными типами данных
>> работает быстрее.

C>Далеко не факт, так как доступ к рядам в таблице RDB тоже может
C>производиться по быстрому идентификатору ряда, если он известен
C>(например, если взят из отношения). То есть при желании RDB будет
C>работать так же быстро, хотя для этого уже нужен нестандартный SQL.
Неверно. OID должен быть инваринтным. То есть уникальным не только при жизни, но и после смерти. С идентификатором ряда (который поддерживается далеко не всеми РСУБД) такое не гарантируется. К тому же, как обеспечить быструю работу с ссылками. И объект не обязательно является кортежом. Объект многомерен.

C>Гораздо интереснее посмотреть другие фичи ODB, например, GC для
C>персистентных объектов. Потом еще интереснее посмотреть как они
C>реализованы в существующих продуктах, и сделать соответствующие выводы.
GC не обязательное условие OODB. Насколько я знаю, в Versant ссылочная целостность обеспечивается тем, что после удалении объекта, все ссылки на него становятся null'ом. В GemStone действительно GC.

С уважением, Gleb.