ООБД на базе clip 0.99.4+patch

Интересная дока. Но я напрочь запутался в их терминологии. %) Тип, класс, объект, элемент класса, экземпляр класса, экземпляр объекта и экземпляр типа. Как все это между собой соотностится?

Много всякой воды, и ни какой конкретики по поводу реализации в конкретной БД. Тривиальный запрос, на который даже смешно смотреть. Пока даже судить не о чём.

гхм, а какой-нибудь математически аппарат к этому? а то чую скоро с ообд бардак начнется

> Интересная дока. Но я напрочь запутался в их терминологии. %) Тип, класс, объект, элемент класса, экземпляр класса, экземпляр объекта и экземпляр типа. Как все это между собой соотностится?

странно, хотели как лучше т.е. прояснить эти понятия и снять подобные вопросы а получилось почему-то непонятно. Странно то что эти понятия не мы придумали и даже можно сказать что эти понятия "сперты" из указанной внизу литературы

> Много всякой воды, и ни какой конкретики по поводу реализации в конкретной БД.

Воду тоже надо писать - без нее вообще ничего не будет понятно

>Тривиальный запрос, на который даже смешно смотреть. Пока даже судить не о чём.

Запросы в ООБД совсем не главное - это не реляционная алгебра, в ранних ООБД вообще не было никаких языков запросов. И разве в качестве примера надо обязательно приводить сложнейшее выражение на котором можно голову сломать только ради того чтобы показать "как это круто" ?

И судить уже есть о чем - но если вы этого не заметили ..... будем писать доку дальше.

>гхм, а какой-нибудь математически аппарат к этому? а то чую скоро с ообд бардак начнется

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

Дока будет развиваться вплоть до описания самых низкоуровневых структур, классов и т.п.

А как будете разбираться с многопользовательской работой, транзакциями и целостностью данных. Одно дело плоские таблицы свойственные xBase, а совсем другое - объекты со всеми их связями?

А как будете разбираться с многопользовательской работой, транзакциями и целостностью данных? Одно дело плоские таблицы свойственные xBase, а совсем другое - объекты со всеми их связями?

>А как будете разбираться с многопользовательской работой, транзакциями и целостностью данных. Одно дело плоские таблицы свойственные xBase, а совсем другое - объекты со всеми их связями?

Хороший вопрос :) транзакции делаются легко, но чтобы это понять надо знать как именно храняться объекты, а этого пока в доке нет и можно сказать что это пока секрет. Объекты и их связи ? котролируются так же как и связи между записями - триггерами или если рассматривать с объектной точки зрения - обработчиками событий, т.е. объект перед удалением получит событие "after_delete" и сам отрабатывает как хочет в том числе и контроль своих связей, для удобства контроля перекрестных ссылок сделаем возможность запросить у БД "кто на меня ссылается", но пока такой фишки нет.

В теории все звучит хоть и не ново, но хорошо. :-))) Дока - действительно вода и только для тех, кто вообще не знаком с ооп. Но главный вопрос в практике. Как все это будет выглядеть в жизни. Планируются ли какие-либо базовые модули, или все делать с нуля руками ?? Если "да", то какие модули ?? Какого уровня ?? Если нет, то зачем изобретать велосипед/еще один язык программирования ??

>В теории все звучит хоть и не ново, но хорошо. :-))) Дока - действительно вода и только для тех, кто вообще не знаком с ооп. Но главный вопрос в практике. Как все это будет выглядеть в жизни. Планируются ли какие-либо базовые модули, или все делать с нуля руками ?? Если "да", то какие модули ?? Какого уровня ?? Если нет, то зачем изобретать велосипед/еще один язык программирования ??

не понимаю о каких "модулях" идет речь ? велосипедов типа ООДБ что-то не очень-то и много и их недостатки настолько серьезные что пользоваться ими себе дороже. Язык программирования clipper/xBase тоже на велосипед не похож - его возраст около 20 лет, вполне зрелый возраст для того чтобы иметь много опыта и готовые решения на многие случаи в жизни программеров.

>Хороший вопрос :) транзакции делаются легко, но чтобы это понять надо знать как именно храняться объекты...

А какой у вас будет уровень изоляции транзакций?

А как ООБД стоит индексы, есть ли какие-нибудь ограничения?

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

* вынуждать пользователей, помещать атрибуты-кандидаты на создание индексов, в открытый интерфейс классов; * разрешить ООБД строить индексы по резултатам, возвращаемым операциями из открытого интерфейса объектов.

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

> А какой у вас будет уровень изоляции транзакций?

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

Hi, lucky

> А как ООБД стоит индексы, есть ли какие-нибудь ограничения?

>Умные книжки по ООП рекомендуют помещать атрибуты в закрытую часть [skip]

отличный вопрос !!!! чуствуется уже пытался. и даже почти ответил сам.

инкапсуляции в ООБД фактически нет и не только в нашей, даже в качестве примеров и в ODMG и в книге одного из разработчиков ODMG (Дэвид Джордан: обработка ООБД в С++) приводяться такие выкрутасы типа "используйте _attribute" именно аттрибут с начальным подчеркиванием для доступа в запросах к инкапсулированным данным. Если рассматривать инкапсуляцию вообще - то ее нет ни в одном языке по одной простой причине - если есть данные в памяти процесса то к этой памяти можно обратится не получив SIGSEGV, и если есть код в сырцах - значит этот код есть в бинарнике и его можно выполнить!!! вся инкапсуляция заключается в том что нет ДОКУМЕНТАЦИИ КУДА КОМПИЛЯТОР СКЛАДЫВАЕТ ИНКАПСУЛИРОВАННЫЕ ДАННЫЕ И КОД. Зная эту недокументированную информацию можно легко обращаться и к методам и к аттрибутам. А если точнее - то инкапсуляция работает только во время компиляции, но не во время обращения к ХРАНИМЫМ ОБЪЕКТАМ. Инкапсуляция - вообще искуственное понятие, которого не существует в реальной жизни - попробуйте спрятать свой номер домашнего телефона ? Думаете его сложно найти если есть острое желание ? А если кому не надо - дык и прятать незачем .

жду еще подобных вопросов и хороших деловых обсуждений.

uri@itk.ru

> А как ООБД стоит индексы, есть ли какие-нибудь ограничения?

небольшой довесок - ограничение таки есть - например если захочешь проиндексировать слишком длинный аттрибут или выражение (200 символов) то индекс построиться только по первым XX сивмолам - это ограничение управляется на этапе компиляции и ограничено только желанием тратить лишнее место на диске под "пустышки" - по умолчанию стоит не более 20 байт на один ключ. Хвосты просто не будут участвовать в индексации, но это не имеет никакого отношения к инкапсуляции

"не понимаю о каких "модулях" идет речь ?"
К примеру - таблица (да, таблица !!!, которая хоть и объект, но все равно ведь таблица :-))) ) при добавлении/обновлении которой будет автоматом выполнятся заранее написанный код ? (Триггеры, короче :-)) ) Или все это (не код триггера, а код, обеспечивающий выполнение триггера) надо самому лепить ?? Речь идет о "базовых классах", какие они будут и будут ли ?

"велосипедов типа ООДБ .... Язык программирования"
Речь об этом и идет - вы чего делает то ?? Прикручиваете нужные фичи к клипу, что бы на нем можно было написать ООБД или пишете саму ООБД с биндингом на клипе ??

"опять мышление реляционной алгеброй"
База данных -> Двумерная Таблица -> Реляционная алгебра :-))) Путь короток и обходных путей пока не очень то и видно.Где-то срезать, где-то подсократить может и надо, а вот идти совсем в обоход вряд ли имеет смысл.

"Инкапсуляция - вообще искуственное понятие, которого не существует в реальной жизни"
Нуууу.. Опять начинаеться.
Инкапсуляция - удобная форма организации областей видимости. Так пойдет ??? :-))))))

"А какой у вас будет уровень изоляции транзакций?"

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

Изоляция транзакций ни как не связана с реляционной алгеброй. Вы говорите про D. А как же ACI (что намного сложнее)?

Hi, lamerOk >"не понимаю о каких "модулях" идет речь ?" К примеру - таблица (да, таблица !!!, которая хоть и объект, но все равно ведь таблица :-))) ) при добавлении/обновлении которой будет автоматом выполнятся заранее написанный код ? (Триггеры, короче :-)) ) Или все это (не код триггера, а код, обеспечивающий выполнение триггера) надо самому лепить ?? Речь идет о "базовых классах", какие они будут и будут ли ?

таблиц нет, есть классы, классу можно повесить триггера (вернее обработчики событий), код обработчика события придется писать самому - ООБД не может знать чего там надо делать в случае допустим удаления объекта.

>"велосипедов типа ООДБ .... Язык программирования" >Речь об этом и идет - вы чего делает то ?? Прикручиваете нужные фичи к клипу, что бы на нем можно было написать ООБД или пишете саму ООБД с биндингом на клипе ??

мы на клипе пишем ООБД, именно так и никак иначе, вся ООБД писана только на клипе потому-что весь объектный движок (события, методы, вызываемые процедуры, .... короче весь код предметной области) тоже пишется на клипе. Есть движок - "виртуальная машина клип" для нее написано ядро ООБД, наружу выставлены методы трех классов для прямой работы и с десяток функций такие как codb_oql_select для организации "запросной" части.

>"опять мышление реляционной алгеброй" >База данных -> Двумерная Таблица -> Реляционная алгебра :-))) Путь короток и обходных путей пока не очень то и видно.Где-то срезать, где-то подсократить может и надо, а вот идти совсем в обоход вряд ли имеет смысл.

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

Короче в общем случае каждый хранимый объект уникален и нельзя совокупность объектов представить какой-либо таблицей. Тем более что атрибутами объекта могут быть другие объекты, массивы объектов и вообще все что захочешь - есть аттрибут типа "X" - в него можно ложить вообще что захочет программист и ядро не будет контролировать этот аттрибут.

>"Инкапсуляция - вообще искуственное понятие, которого не существует в реальной жизни" Нуууу.. Опять начинаеться. Инкапсуляция - удобная форма организации областей видимости. Так пойдет ??? :-))))))

Где это удобно ? Лом против чайников-начинающих программистов ? А вот в ООБД - это огромный тормоз и невозможность проиндексировать и делать запросы по спрятанным данным.

Ограничить видимость можно и через "секурити" и с точки зрения БД - это более правильный путь.

>"А какой у вас будет уровень изоляции транзакций?" >"опять мышление реляционной алгеброй :) теоретически любой по желанию, в ральности - транзакции это просто "запись всех событий от начала и до конца" и в случае необходимости откатиться "генерация обратных событий", ну а на дальнейшее - вопрос открыт и для советов и для решения и для реализаций."

> Изоляция транзакций ни как не связана с реляционной алгеброй. Вы говорите про D. А как же ACI (что намного сложнее)?

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

Вопрос о транзакциях в ООБД пока открыт в том числе и для советов "как можно красиво реализовать" .

anonymous (*) (2002-08-16 06:15:10.818)

Вы что, народ !!!!!!!!!!! Только нормальное ядро базы нужно разрабатывать несколько лет Интерсистемс (www.intersys.com, www.intersystems.ru) на разработку об`ектной оболочки на готовую СУБД потратил 6 лет и то она и сейчас не до конца совершенна. А здесь предлагают некую "поделку", которая еще и теоретически еще не до конца проработана.

О сколько чудных вешей подарила компания компания ИТК! Разработчик управленческого софта, как они себя позиционируют, подарил нам Clip, ООБД(новое поколение СУБД от ИТК, старая СУБД от компании базировалась на сетевой/иерархической модели). Известный аналитик uri@itk.ru обосновал непригодность реляционной модели и SQL в частности для серьезного управленческого софта. Подождем немного, может uri@itk.ru напишет какой нибудь научный труд по основам ООБД и докажет превосходство над теорией Кодда, пока только они детские рассказики сочиняют. ИТК - маразматическая контора, которая прежде чам написать прикладную программу сначала создаст свой язык, потом напишет свой копилятор, потом создаст новое направление в СУБД и реализует его на практике. Куда там 1C и Парусу до ИТК! Я с ними общался довольно много и уяснил что с такими конторами дел лучше не иметь. Видел результаты сотрудничетва с ИТК на практике - большие деньги выброшенные на ветер.

С гражданином uri@itk.ru вообще трудно спорить. Такое чувство, что он просто дятел.

Чтобы поднабраться опыта, как пишутся и что должны уметь делать ОО СУБД советую почитать книгу Кирстена "субд Cache - об`ектно-ориентированная разработка приложений" издательства "Питер" или взять на офисе InterSystems в Москве учебный курс для студентов МИФИ.

Напрасно ты так, про инкапсуляцию. В статье дано весьма глючное определение данного понятия. На самом деле это немного другое: объединение данных и функций для их обработки плюс сокрытие их фактической реализации. Вобщем смысл тут не поскрывать все подряд, а закрыть именно реализацию (от которой простым смертным все равно проку нет =)). Нафиг надо?

Ну во первых, как ты точно подметил -- в качестве лома против чайников, неразумных хацкеров и прочих ООБД ;), дабы не тратить собственное время на полит.разъяснения: "Конкретная реализация функций и атрибутов объекта являтеся вотчиной их разработчиков -- если захотят, перепишут по-другому. А посему привязывать свои разработки, индексы ;) и т.п. к особенностям конкретной реализации -- кулхацкерство и ламеризм."

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

В третьих, "формальной основой понятия инкапсуляции является теория абстрактных типов данных". А это не номер телефона прятать -- это предпосылка для представления класса как АТД, и как следствие -- возможности формальной верификации ОО системы.

Поэтому в сад такую БД, которая станет принуждать пользователей отходить от инкапсуляции. ;)

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

Вообще интересный проект. Кстати, в каких задачах, по вашему мнению можно будет применить ООБД?

Тот же anonymous что и (2002-08-16 06:15:10.818) (Забыл логин)

ИМХО реляционной модели вполне достаточно для большинства прикладных задач (типа учета и др.), а с приходом модели данных XML в СУБД будет еще достаточнее. А это без сомнения произойдет, взгляните на XQuery. Даешь Semantic Web!

Hi, aladkoi >Вы что, народ !!!!!!!!!!! Только нормальное ядро базы нужно разрабатывать несколько лет Интерсистемс (www.intersys.com, www.intersystems.ru) на разработку об`ектной оболочки на готовую СУБД потратил 6 лет и то она и сейчас не до конца совершенна. А здесь предлагают некую "поделку", которая еще и теоретически еще не до конца проработана.

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

И чтоже теперь если существует кеш то другим продуктам быть нельзя ? оригинальная позиция. Ну чтож пусть тогда будет одна ОСь, один браузер, один офис, .....

to злобный анонимус: а еще в итк пьют пиво и водку, закусывают рыбой и колбасой, ругаются матом, и много других недостатков и даже вы не поверите - КУРЯТ, но не траву. Скажи свое имя и твои недостатки тоже можно будет опубликовать. Слабо раскрыться ?

Hi, lucky > Ну во первых, как ты точно подметил -- в качестве лома против чайников, неразумных хацкеров и прочих ООБД ;), дабы не тратить собственное время на полит.разъяснения: "Конкретная реализация функций и атрибутов объекта являтеся вотчиной их разработчиков -- если захотят, перепишут по-другому. А посему привязывать свои разработки, индексы ;) и т.п. к особенностям конкретной реализации -- кулхацкерство и ламеризм."

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

С этой точки зрения инкапсуляция в ООБД должна быть юзеро-зависимой :) но при этом сама ООБД должна работать с объектами имея рутовские права на "документацию" - т.е. для ядра ООБД никакой инкапсуляции нет.

и ООБД не принуждает отказываться от инкапсуляции - пожалуйста используйте где-нибудь там ..... в програмном коде .... а вот в хранилище - ядро ООБД имеет доступ ко всем атрибутам всех объектов.

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

легко :) зависит только от фантазии. Есть фантазия - напиши что на тебе "наглючила" в этой области.

> Вообще интересный проект. Кстати, в каких задачах, по вашему мнению можно будет применить ООБД?

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

> ИМХО реляционной модели вполне достаточно для большинства прикладных задач (типа учета и др.), а с приходом модели данных XML в СУБД будет еще достаточнее. А это без сомнения произойдет, взгляните на XQuery. Даешь Semantic Web!

это ваше мнение вы его и реализуйте, но не мешайте мне иметь другое мнение. Я на это имею полное право. XML только пришел в РМ, а в клипе оно от рождения. Сами наверное догадыватесь что сбросить/зачитать объект в/из XML - это как 2 байта переслать. И хуже того - "словарь" является готовой БД для UML дизайнера - только морду ему написать.

uri@itk.ru

"таблиц нет, есть классы"
"Нету в ООБД таблиц, есть хранимые объекты"
Ядрен батон, а классы __реализующие__ хранение данных (других, ясен пень, классов) в форме таблицы ??? Они есть или самим на тему двумерных массивов извращаться ?? Не уж то я такое сложное понятие имею в виду, что и понять меня совершенно не возможно ?? :-)))

"классу можно повесить триггера (вернее обработчики событий)"
Я знаю, что такое "методы класса".

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

"Где это удобно ?"
Везде, где задача (особенно, с учетом ее будущего развития) сама "ложиться" на ОО модель. Скажем, ООБД :-))))))))

"это огромный тормоз и невозможность проиндексировать"
Если данные в массиве/списке/иной структуре, то кто мешает ???

" и делать запросы по спрятанным данным. "
Если данные "спрятали", то видимо не от балды ??? Какой идиот, положив завещание в сейф, будет жаловаться, что его нельзя прочесть не достав ???

ЗЫ. 2 местным злобствующим анонимусам.
Я так погляжу, в каждом треде прямо или косвенно посвященным ИТК найдется несколько хаятелей. Господа хаятели, а чего конкретного лично ВАМ сделали люди из ИТК. Брали родственников в заложники, с утюгами приходили или чего ?? И если ответ будет "ничего", то какого хрена вы выступаете то ?? Вы считаете их идеи глупыми и маразматичными ?? Но они заслуживают быть выслушанными хотя бы потому, что они эти идеи __реализуют__. В отличии от большинства местных 3.14...болов, к каковым скорее всего относитесь и вы.

Hi,lamerOk ! > "таблиц нет, есть классы" "Нету в ООБД таблиц, есть хранимые объекты" Ядрен батон, а классы __реализующие__ хранение данных (других, ясен пень, классов) в форме таблицы ??? Они есть или самим на тему двумерных массивов извращаться ?? Не уж то я такое сложное понятие имею в виду, что и понять меня совершенно не возможно ?? :-)))

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

> "Короче в общем случае каждый хранимый объект уникален и нельзя совокупность объектов представить какой-либо таблицей." Т.е. создав классы "имя", "серия паспорта", "мафизоная крыша" и запихнув их в класс "сторка", я не могу составить объект-массив из этих классов ?? Или даже класс "строка" создать не могу ??? Стаю, я знаете ли на асфальте, в лыжи, само собой, обутый.. :-)))))))

Сможешь, только не понимаю зачем нужно делать класс "строка" если есть тип "строка", если дело только в имени "строка", то такое слово "string" не забронировано в ядре ООБД - можешь его использовать на здоровье, создать для него аттрибуты data,len, нужные методы/ события и пользуй на здоровье. Только нет никакого смысла создавать именно "string". Надеюсь что это было выбрано только для примера. Или я вообще не понял смысл примера или мы опять думаем по разному или о разном. Попробуй описать что-то более жизненное и легко понимаемое.

> "Где это удобно ?" Везде, где задача (особенно, с учетом ее будущего развития) сама "ложиться" на ОО модель. Скажем, ООБД :-))))))))

Так в этом конкретном случае ("проект ООБД") инкапсуляция вредна :) А вот когда "хранимый" объект выходит из контроля ООБД и переходит в "программерский" разряд - пусть и "прячет" часть своих возможностей от несанкционированного использования. Но это уже вопрос удобства "программирования" и "лом против чайников" а не удобства "хранения" и обработки данных.

> "это огромный тормоз и невозможность проиндексировать" Если данные в массиве/списке/иной структуре, то кто мешает ???

Только если ядро ООБД имеет доступ ко всем инкапсулированным данным.

>" и делать запросы по спрятанным данным. " Если данные "спрятали", то видимо не от балды ??? Какой идиот, положив завещание в сейф, будет жаловаться, что его нельзя прочесть не достав ???

Нотариус, который составлял и заверял текст завещания имел к нему полный доступ и хошь-нехошь а что-то помнит :) Это и есть "супердокументатор" или ядро СУБД. При "заверении завещания" (а это не что иное как проверка на "содержание объекта принадлежит классу завещание") ведь можно и проиндексировать :) а вот другим "юзерям" доступа нет - только через нотариуса, который в принципе может ответить на некоторые не очень "секурные" вопросы касающиеся содержания завещания. Или например в суде под присягой или под действием "горячего утюга".

Это я к тому что в природе не существует понятия или явления "инкапсуляция", это понятие искуственно введено в процесс разработки ОО-программ, но не для ООБД, по крайней мере ни в одной литературе про ОО-проектирование нет ссылок на ООБД :). Попытки применить инкапсуляцию к ООБД приводят к фишкам типа "не используйте в запросах аттрибут len, потому-что это метод, используйте аттрибут _len, и хотя он инкапсулирован но в OQL запросах доступен" - примерно так написано в книге одного из разработчиков ODMG (Дэвид Джордан: Обработка объектных БД в C++)- не я придумал подобную фенечку. Где у них-то логика ? И объясните мне плиз чем лучше "пользуйте _len" от нашего подхода ? Неужели лучше использовать недокументированные ODMG фишки, только из-за того что ODMG ориентируется на соответсвие и прозрачность со строго типизированными языками ?

Да у нас ООБД сделана не так как рекомендует ODMG. И не только в части инкапсуляции. Щаз мне опять припомнят Кодда :)

"мы опять думаем по разному или о разном."
Именно :-)))
"Ты пытаешься представить как реализована CODB "
Вот в этом и была загвоздка. Я говорил в данном случае не с точки зрения реализации ООБД, а с точки зрения ее пользователя. Т.е. мой вопрос заключался в том, как будет выглядеть ООБД для пользователя-программиста. Чего он получит то в итоге ???

"зачем нужно делать класс "строка""
Имелась в виду не строка текста, а строка таблицы. Нужно ли ее (класс содержащий строку таблицы) делать, а потом запихивать в массив (который соответственно будет представлять таблицу), или же будут какие-либо готовые классы представляющие таблицу ?? Или вообще для работы с ООБД не нужно будет ничего программировать и все будет делать секретарша ??? :-))))

"Это я к тому что в природе не существует понятия или явления"
Существует, (хоть это флейм и не по теме). Руль у автомобиля когда крутите, можете ведь и не знать, как он устроен ?? С гидравликой или без. Правда это можно почувствовать, но то же верно и в отношении методов класса :-)))) Инкапусляцией считаеться (некоторыми) даже скрытие областей видимости в обычных процедурных функциях. А это вредным еще никто не называл. :-))))))

А что это сегодня LOR полдня не работал ?

Hi, lamerOk ! >>"Ты пытаешься представить как реализована CODB " >Вот в этом и была загвоздка. Я говорил в данном случае не с точки зрения реализации ООБД, а с точки зрения ее пользователя. Т.е. мой вопрос заключался в том, как будет выглядеть ООБД для пользователя-программиста. Чего он получит то в итоге ???

ООБД может выдавать:

1. готовый к использованию объект (в виде XML, через CORBA, CLIP-объект, возможны и другие варианты) CORBA еще не реализована, "другие варианты" - предлагайте какие надо по вашему мнению ?

2. Список идентификаторов объектов - как результат работы БД-процедуры

3. Класс idList (нечто похожее на rowset) как результат работы "select"

4. события, которые вызывают отбработчики событий.

>>"зачем нужно делать класс "строка"" >Имелась в виду не строка текста, а строка таблицы. Нужно ли ее (класс содержащий строку таблицы) делать, а потом запихивать в массив (который соответственно будет представлять таблицу), или же будут какие-либо готовые классы представляющие таблицу ??

Зачем представлять "таблицу" ? Нету таблиц в ООБД. Можно условно считать что объект - это строка таблицы, а совокупность объектов одного класса - это таблица, но только условно и для более быстрого понимания для тех кто не владеет ОО-мышлением. Точно также как объект С++ можно условно считать структурой Си, потому как в Си нет аналога объектов С++.

>Или вообще для работы с ООБД не нужно будет ничего программировать и все будет делать секретарша ??? :-))))

Если скрестить "флору" (www.compassplus.ru) с CODB вполне возможно что программист будет требоваться намного реже. Между прочим - смеется тот кто смеется от души :)

>>"Это я к тому что в природе не существует понятия или явления" >Существует, (хоть это флейм и не по теме). Руль у автомобиля когда крутите, можете ведь и не знать, как он устроен ?? С гидравликой или без. Правда это можно почувствовать, но то же верно и в отношении методов класса :-))))

считаешь меня чайником ? ну-ну ! так и действуй дальше.

Как устроен "руль" внутри не знает только начинающий водитель и то при условии что он САМ НЕ ХОЧЕТ ЭТОГО ЗНАТЬ. ООБД в данном примере совсем не "водитель" а тот самый "руль", который исполняет приказы "водителя" и не знать об устройстве "руля" ООБД просто не имеет права. Плохой пример однако.

>>Инкапусляцией считаеться (некоторыми) даже скрытие областей видимости в обычных процедурных функциях. А это вредным еще никто не называл. :-))))))

Да на здоровье ! Только где там написано что это касается ядра ООБД ?

Щаз опять начнется "с ним невозможно спорить" ! Дык вы же сами применяете "методы программирования" в качестве "методов хранения".

Попробуйте сами описать что должна/недолжна делать ООБД с инкапсулированными данными. Допустим имеется класс "string" у него (как советует классика ОО-проектирования) есть скрытые аттрибуты "_data" и "_len" и открытые методы "setdata","getdata","setlen","getlen".

Вот и попробуйте описать: 1. как будет выглядеть выражение для индексов ? 2. как будет выглядеть выражение where ?

_Объект_ не содержит атрибутов, ни скрытых, ни открытых. Он получает сообщения. А как он сохраняет свое состояние - это его (объекта) личное дело.

"ООБД может выдавать: "
Это уже другая крайность. Я говорю о этапе проектирования самой базы данных !!! Как она будет выглядеть ?? Как редактирование исходников ООБД ?? :-))))

"Зачем представлять "таблицу" ? Нету таблиц в ООБД."
Зато есть данные, которые а) надо автоматически обрабатывать и б) их для этого удобно засунуть как минимум в двумерный массив (лучше бы и в более, но с этим пока совсем туго) сиречь таблицу.

"смеется тот кто смеется от души :) "
В смысле "хорошо смеется" ?? Так я только от нее, от родимой (от души т.е.) и смеюсь. :-))

"Только где там написано что это касается ядра ООБД ?"
А где я говорил об инкапсуляции в отношении ООБД ?? Вы приписали мне утверждение "реализация ООБД должна позарез поддерживать инкапсуляцию" и очень убедительно с ним спорите. :-)) А я лишь утверждаю, что инкапсуляция - полезная вещь. Безотносительно как ООБД, так и чего-либо конкретного. Если, как и со всем хорошим, не перебирать. :-))) Относительно реализации ООБД я вообще никаких ни утверждений, ни предположений не делаю. Я пока пытаюсь понять, что вы собственно делаете то. :-)))

Hi, lamerOk>>"ООБД может выдавать: " >Это уже другая крайность. Я говорю о этапе проектирования самой базы данных !!! Как она будет выглядеть ?? Как редактирование исходников ООБД ?? :-))))

а это уже третья крайность :) я что похож на идиота ? Я ведь могу и вообще исходников не давать :) Проектирование заключается в том чтобы набить "словать" необходимой информацией - через адм.утилиту, изменение внешних xml-описателей и последующей их загрузкой в словарь или допустим через UML-редактор (вот его пока нет)

> "Зачем представлять "таблицу" ? Нету таблиц в ООБД." Зато есть данные, которые а) надо автоматически обрабатывать и б) их для этого удобно засунуть как минимум в двумерный массив (лучше бы и в более, но с этим пока совсем туго) сиречь таблицу.

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

> "Только где там написано что это касается ядра ООБД ?" А где я говорил об инкапсуляции в отношении ООБД ?? Вы приписали мне утверждение "реализация ООБД должна позарез поддерживать инкапсуляцию" и очень убедительно с ним спорите. :-)) А я лишь утверждаю, что инкапсуляция - полезная вещь.

я тоже согласен с этим утверждением .

> Я пока пытаюсь понять, что вы собственно делаете то. :-)))

Вот это крутой вопрос ! даже не знаю что и ответить . Ну скажем так - управляемое хранилище объектов в долговременной памяти компьютера. Пойдет такое определение ?

"Проектирование заключается в том чтобы набить "словать" необходимой информацией - через адм.утилиту,"
А вот с этого места можно по подробней пожалуйста ?? Можно с аналогиями при работе с реляционными БД (для особо тупых, вроде меня).
При работе с реляционной БД я беру саму БД, набиваю ее данными, описываю все view'ы, триггера и прочую муть, а потом подключаюсь к ней всякими апликейшн серверами и пихаю/тырю информацию. Как эта схема соотноситься со схемой работы с ООБД ?? Реляционные БД мне в разной степени гарантируют поддержку ссылочной целостности данных и некие дополнительные возможности по контролю за информацией (все те же триггера и хранимые процедуры). Чего дает ООБД ? Какого рода структуры я могу создавать в ООБД ??

"Двумерный массив - он и есть двумерный массив, а не таблица."
А если к этому объекту-двумерному массиву будет применяться функция "select", он, наконец, станет таблицей ??? :-))))))

Hi, lamerOk! >>Проектирование заключается в том чтобы набить "словать" необходимой информацией - через адм.утилиту," > А вот с этого места можно по подробней пожалуйста ?? Можно с аналогиями при работе с реляционными БД (для особо тупых, вроде меня). При работе с реляционной БД я беру саму БД, набиваю ее данными, описываю все view'ы,

view`ов как таковых нету, есть tview, это практически представление на экране, кто хочет воспользоваться tview - тот воспользуется, но оно только как доп.информация, не а "обязательно к применению".

> триггера и прочую муть, а потом подключаюсь к ней всякими апликейшн

не триггера, а обработчики событий. "прочая муть" тоже есть.

серверами и пихаю/тырю информацию. Как эта схема соотноситься со

CODB и есть аппликейшен сервер в будущем, сейчас как раз и идет работа над тем чтобы стать "сервером".

> схемой работы с ООБД ?? Реляционные БД мне в разной степени гарантируют поддержку ссылочной целостности данных и некие дополнительные возможности по контролю за информацией (все те же триггера и хранимые процедуры). Чего дает ООБД ?

тоже самое дает - контролируй если надо.

>Какого рода структуры я могу создавать в ООБД ??

Хранимый объект может быть любой формы.

>>"Двумерный массив - он и есть двумерный массив, а не таблица." >А если к этому объекту-двумерному массиву будет применяться функция "select", он, наконец, станет таблицей ??? :-))))))

Да. Можно получить событие "begin_select" и выполнить его по-своему, но в случае "двумерных массивов" чтобы была полноценная индексация и выполнение "селект" по индексам придется ловить все события и самому управлять индексами и прочими доп.понятиями.

Просто так без "обработчиков событий" ядро не будет индексировать объекты класса "многомерный массив", но запросы к ним выполнять будет.

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

Кто-то из нас опять что-то не понимает или говорит о разном :) Задать вопрос правильно - уже половина успеха !!!!