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

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

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

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

Статья не впечатлила - обо всем и ни о чем, так рассуждения об "объектности", я сам не работал с объектными технологиями баз данных и хотелось бы услышать не рассуждения и "объективные исторические предпосылки возникновения объектных технологий" (вся статья смахивает на лекцию какого-то отраслевого техникума народного хозяйства по программированию), а примеры, архитектуру и логику работы, плюсы и минусы технологии... Может кто-то другого мнения об этой статье, но я ничего для себя из нее не вынес, и могу написать подобную статью по любому языку или технологии включая те которых я и в глаза не видывал - достаточно прочитать какое-нибудь ревью, и размазать на 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 лет с ним Советую, не пожалеешь Это и есть база данных, одна из самых крутых на сегоднешний день

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

to: Евгений Григорьев

Цитата

Она тоже требует тщательного прочтения. Но это Вам не грозит.

 Не надо заводить старого флеймера. Гвоздями к стенке прибью.
 Но лучше по существу вопроса.

Цитата

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

Отвечаю. Реляционная база в данном проекте на хрен никому не нужна. Почему она у меня есть? По одной простой причине: мне недосуг заниматься собственной основой. Поэтому я взял готовую, в виде давно написанного и вылизанного по быстродействию и надежности MySQL и написал то, чего не хватало. Что же касается настоящих коммерческих ОО баз, там у них внутри реляционной моделью с ее SQL даже не пахнет, а SQL интерфейс эмулируется для возможности быстрого переноса проектов. Получается куда быстрее.

Цитата

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

Статью я не пересказывал, а с ней полемизировал. Теперь объясняю. Тут читать очень внимательно. Потому что прошлый раз объяснение понято не было. Сущность "Вес" обладает атрибутами. В данном случае - это единица измерения. Точно так же, как стол обладает весом, вес обладает единицами измерения. Причем точно так же, как столовладелец обладает столом. Поэтому мы не можем делить вес и его стол на две принципиально разные группы. Начинающие программисты баз данных часто не понимают этого. И поэтому ситуация, когда какой-то объект, использовавшийся ранее в только качестве свойства, начинает иметь свои значащие аттрибуты, ставят их в тупик. Типичый пример: цена товара. Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до. И мы можем наткнуться на эту ситуацию _в любом месте_. Именно поэтому вес у меня - объект. Сразу. И именно в этом одна из причин создания такой базы. Я написал и вот уже два года поддерживаю не самый мелкий в мире электронный магазин. Заказы тут идут мелкие, но часто, т.е. много часов может наблюдаться ситуация, когда в обработке  одновременно находится с десяток заказов. А при уплытии объектной модели (а она плывет непрерывно - это бизнес) надо менять поля. А изменение таблицы - это остановка сервера, потому что никто не может шариться по таблице из миллиона записей, которая прямо сейчас колбасится по alter table. А остановка сервера - это убытки. И причина - в негибкой реляционной парадигме. А в объектной модели мы не меняем никаких таблиц. Никогда. Даже если пользуемся ими в качестве хранилища.

Цитата

Несколько практических вопросов о  системе, созданной Вами. Заметьте, что я спрашиваю именно про систему хранения... про серверную компоненту (что бы было понятнее).

Независима ли она от использующей ее программы?
 Да. Даже в другом каталоге лежит.
Существет ли язык, описывающий ее и служащий для ее управления?
 OQL, примеры которого я приводил в прошлом письме. Похож на SQL - я сделал поблажку своей инерции мышления.

Храняться ли в ней метаданные (я имею в виду хотя бы описание структуры хранимых сложных объектов)?
 Сколько угодно. Стандарта типа DTD я не разрабатывал, но фактически пришел к тому, что кое-что храню. На основе этого делаются редакторы, к примеру.
$form=$shop->$part->createEditForm($object);
$form->printForm();
Вот так я показываю пользователю форму для редактирования любого объекта из базы. Оно берет описание из базы и по нему фигачит нужные поля.

Можно ли получить и изменить метаданные?
       write-only и read-only не предусмотрено.

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

Контролирует ли система то, что при изменении метаданных существующие данные не будут противоречить внесенным изменениям?
 Не-а. Потребуется - напишу.

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

Реализует ли система хранения метаданных хранение методов? Возможно ли выполнение эти методов (на стороне сервере, конечно)?
 В процессе.

Если на эти вопросы Вы ответите утвердительно, то совершенно очевидно, что Ваша работа заслуживает самого пристального внимания.
 Сразу видно теоретика. Практик спросил бы: документация есть? Я ответил бы: НЕТ.

Цитата

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

Это от отсутствия практики, судя по всему. И не надо переносить на других свои мотивы. Уже то, что я вместо монстроузного бэк-оффиса из сотни страниц могу  использовать уже написанный OODB Admin, похожий на Проводник Windows как заспиртованный брат-близнец, и дописать пару специализированных страниц для менее продвинутых админов, типа начальства и девочек, что письма обрабатывают, уже оправдывает написание OODB. И миллион других аспектов, о которых теоретики просто понятия не имеют. Например, надо мне сейчас несколько индексов в таблицы добавить. (Кто хочет писать про плохое проектирование - лезть выше и читать три раза про изменение объектной модели). Мне придется сделать это завтра днем, в минимум заказов. А перед этим я сидел и разбирался с протоколом медленных запросов. И потратил я на это уже несколько часов. При чем тут OODB? Там такого случиться не могло. В принципе. Второй аспект из миллиона. Далее продолжать не буду - каждый вспомнит сам исходя из своего опыта.

WTB, программный монстр занимает 61K кода. Без ooforms - 49K. Сама основа, которую уже можно использовать (без OQL) - 20K в одном файле.

to: crimaniak
ОК!

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

Во-первых,  хочу придраться к фразе "МОДЕЛЬ ПЛЫВЕТ". МОДЕЛЬ НЕ МОЖЕТ ПЛЫТЬ! То что может плавать называется "схема данных, описывающая моделируемую предметную область реализованная в рамках модели данных". Например: в рел. БД есть несколько таблиц описывающих склад. Описание этих таблиц и есть схема данных. Можно менять таблицы, можно добавлять новые, можете устанавливать новые связи - другими словами можно менять схему данных, но реляционная модель от этого не меняется и, всен эти изменения происходят в рамках реляционной модели.  Точно так же и про объектную схему данных описывающих некий бизнес.

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

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

Но все это с теоретической точки зрения А с практической - лишь бы работало, и что бы влезать пореже ))) Я серьезно, сам все знаю, именно поэтому и заморачиваюсь теорией....

Цитата

Во-первых,  хочу придраться к фразе "МОДЕЛЬ ПЛЫВЕТ". МОДЕЛЬ НЕ МОЖЕТ ПЛЫТЬ! То что может плавать называется "схема данных, описывающая моделируемую предметную область реализованная в рамках модели данных".

 Да, я имел в виду схему данных.

Цитата

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

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

Цитата

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

Да я уже два длинных опуса написал на эту тему! Я уж не знаю, как еще объяснить, что унификация всех сущностей как объектов ведет к громадному упрощению объектной модели. Как ни крути, а объекты - это не более чем точки в многомерном гиперкубе их параметров, причем у этого пространства имеет место преобразование, когда бывшая ось становится точкой. И в реляционной модели мы эмулируем эту ситуацию при помощи отдельно взятых сечений, а в объектной непосредственно задаем. У нас есть три таблицы - поставщики, клиенты и товары. Мы взяли и сделали формочку на сайте для отзывов обо всем этом. Таблица для отзывов. Как будем связывать? А никак! Занимаемся эмуляцией. Вот поле типа - к чему относится отзыв, вот ID объекта в его таблице. Программа лезет в поле типа, а потом - банальный switch(). Есть такая проблема в OODB? Нет! Благодаря чему? Именно этому, "все есть объект". Вот захочу и выберу все объекты в базе, у которых вес - 20 кг, и которые синего цвета. Независимо от того, в какой ветке они лежат - столы это, клиенты с Марса или свадебные торты. Вот еще штука: когда я начал работать с OODB админом, выяснилось, что он легко дает всякого рода статистику, при помощи одной и той же страницы. Например, вогнал я туда рестораны Москвы - и могу сразу выбрать рестораны у данного метро или с данной кухней, или данной ценовой категории. Или посмотреть статистику значений любого свойства в базе (там легко ошибки вылавливать). В общем, бесполезно описывать, надо поработать...

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

Цитата

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

В реляционной модели надо создавать таблицу. В объектной - не надо.

ОК!

С первым проехали

Второе (кстати на основе первого). То, что инкапсулировано в объектах - это описание схемы данных в рамках модели. Меняя схему данных в реляционной модели вы (всего лишь!) меняете схему данных, но не саму модель. В теории рел БД есть такие вещи как домен, отношение и операции над отношениями - и это все(!), чем оперирует реляционная модель. В книге "Теория реляционных БД" написанной на более чем 400-х станицах нет ни слова о такой штуке как "сервер", и о такой операции как "остановка сервера". Да, реляционную модель называют невыразительной, но это только потому, что ИМХО от нее требуют большего, чем то, на что она реально рассчитана. Да. говорят про "потерю семантики", но ИМХО не модель тому причиной, а глобальное непонимание того, что семантика - это в принципе такие же данные (во-всяком случае она кодируется значеними...словами). Я хочу показать, что возможна  такая органихация реляционной системы хранения данных, когда вся информация, описывающя любую прикладную область будет сохраняться в полном объеме, вместе с семантикой и возможностью организовать объектную организацию данных.

Как бы это объяснить на пальцах? Вот есть память (компьютерное ОЗУ) про которую можно сказать, что она линейная. Единственная ее задача - хранить данные и с этой задачей она справлется достаточно хорошо. Она действительно хранит данные,  и код, оперирующий над этими данными . Заметьте, никто не требует, что бы эта линейная память была выразительной и служила для описания моделируемой предметной области. Это ОЗУ можно назвать системой. Информация в этой системе храниться в ....ну назовем это ячейками памяти.

Раньше (давным-давно, во времена ассемблеров) это был верхний уровень организации данных. А потом стали появляться системы которые позволяли ПРЕДСТАВИТЬ информацию, хранящейся в ОЗУ организованной по-другом - в виде объектов. Это был ...ммм... несколько эволюционный  процесс. Важно то, что эти "представляющиеорганизованнымиподругому" системы, являются НАД(!)системами по-отношению в ОЗУ. Они построены не ВМЕСТО нее, а НАД ней. Для своей работы им приходиться хранить в том же(!) ОЗУ данные описывающие организацию других данных (метаданные). Но эта разниза (между данными и метаданными) возникает только на уровне НАДсистемы. Важно понять, что в ОЗУ для этого ничего менять не приходиться - там вся информация по-прежноему храниться в ячйках памяти.

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

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

Цитата

А вот Вы почему упорно отрицаете подход, когда вес - тоже объект, несмотря на приведенные примеры его эффективности?

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

Кстати, исходя из моих построений "поставщики, клиенты и товары" так же бы ли бы объектами. Но вот такие вещи как вес, цена, адрес  - это НЕ ОБЪЕКТЫ. Разницу я объяснил.

Цитата

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

Загадочная для меня фраза. Так Вы про модель или про схему? В любом случае в объектная концепция изначально подразумевает, что любая сущность описывается в виде объекта. Именно с этим я и спорю.

Тут Евгений Григорьев задал мне вопрос на личную почту: "Можно ли публиковать ссылки на эту обсуждаемую тему?".

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

r vs o опускаю, раз у нас реляционная модель - это одно, а базы на ее основе - это, оказывается, совсем другое. Сравнение с ассемблером правильное. Так же, как вредно программировать на ассемблере, так же и пользуясь реляционной парадигмой. Отмечу только распространенную ошибку: свойства, приписываемые ассемблеру, в большей мере относятся к программированию в кодах (хотя кто сейчас помнит ДВК-1, Б3-34 и прочее в этом роде?). В ассемблере у нас уже есть символические имена, структуры и прочие вещи, позволяющие нам абстрагироваться от линейной модели памяти.

Цитата

Потому, что модель должна адекватно описывать сущности предметной области. Пример на пальцах. Есть два яблока с одинаковым весом. Пусть вес в граммах. Вдумайтесь в фразу. Описываем. Пусть (как вы хотите) все объекты - два объекта и два атрибута - тоже объекта. Всего получили четыре объекта - два яблока и два веса. Вдумайтесь в то,что мы получили. Было три(!) сущности - два яблока и ОДИНАКОВЫЙ(один и тот же!) вес, а получили четыре объекта. А почему? Да потому что мы описали вес как объект, что подразумевает существование уникального объектного идентификатора OID (это основа объектной концепции!). Знаете принцип Оккама - "не умножай сущности сверх надобности"? Так вот - здесь мы его нарушили.

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

Код

[Яблоко1] ----<210>---->  [Вес] <-----<260>------ [Яблоко2]                            |                         <грамм>                            |                            v                   [Единица измерения]

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

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

Цитата

Загадочная для меня фраза. Так Вы про модель или про схему? В любом случае в объектная концепция изначально подразумевает, что любая сущность описывается в виде объекта. Именно с этим я и спорю.

 "... о вкусе ананасов..." (с) Жванецкий.
Just try it!

to: crimaniak
OK!

Ну то, что реляционная модель и современные реляционные СУБД (точнее SQL-СУБД) имеют значительные (принципиальные!) несоответсвия - так это слава богу не моя мысль. Вот ссылка на сайт DataBase Debunking, где одним из авторов является Крис Дейт, очень известный спец.  и по реляционной модели и по БД вообще. Там очень много интересных материалов по данной теме.

Схему я посмотрел в правильном фонте. И возникли у меня вопросы.  Из схемы неясно, а что же является переменной для значений 210 или 260. Поясню. Есть такие фундаментальные понятия. Значение - это информация, а переменная - это ...ммм... место где эта информация находиться. В объектной концепции вполне четко звучит, что любая переменная - это объект. Вот у вас ЗНАЧЕНИЯ 260 и 210 они где? Переменные, содержащие их - это что? это объекты? Тогда у вас 5(!) объектов. Но если не объекты, а характеристики связи, т.е. ОТНОШЕНИЯ (англ: relation) между объектами,  то я хочу сказать вам следующее

1) Вы высказываете идеи, которые более 20 лет назад высказывались Румбаухом и ныне активно развиваются Дейтом (на том же сайте очень много инф. про это), и которые совсем НЕ противоречат реляционной модели. Его цитату по этому поводу я привожу в самом начале моей второй статьи. Вот она: "в реляционной модели не существует ничто, что может ограничить скалярные значения, существующие в доменах, … простыми формами. … эти скалярные значения могут быть настолько сложными насколько мы пожелаем". В данном случае мы говорим об отношении на доменах  "яблоки","значения","вес" и об отношении на доменах "вес","значение","единицы измерения". ИМХО Вы черезчур усложняете схему. Вот ситуация: один вес измеряется в граммах а другой - скажем в унциях . У меня это будет выглядеть так: яблоко1(200,"граммы"), яблоко2(500,"унции"). Но схема то не поменялась. А у Вас? Я что-то не могу понять, как она будет выглядеть (похоже должен появиться второй объект "вес", связанный через "унции" с "единицами измерения").

2) Возможно Вам это покажеться странным, но то, что вы говорите,является ЧАСТНЫМ случаем моих постоений. Понимаете, они позволяют реализовать любую схему, в том числе и вашу.  Еще раз говорю - мои построения теоретические, хотя и приводят к достаточно простой и однозначной практической реализации. Я тоже могу создать классы "явлоки","вес", "единицы измерения" и  строить отношения между ними (которые кстати у меня хотя и направлены, но.... одновременно и ненаправлены, и поэтому по ссылкам я могу гулять туда и обратно ) . Я просто не буду создавать классы "вес"  и "единицы измерения", потому как для для сравнения и идентификации одноименных сущностей необходимо и достаточно их явно заданное значение, поэтому я опишу эти сущности как качество. Точнее я создам одно качество "вес" с несколькими полями "значение", "единицы измерения", а для того что бы определить домен для "единиц измерения" вовсе не буду создавать класс - для этого есть другие возможности.

Наконец - так вы с чем спорите? - со моими построениями или с реляционной моделью? Если с реляционной моделью, то о ее выразительности и гибкости  я уже устал писать. Если с моими построениями, то я просто не буду вам пересказывать мои статьи - ну просмотрите вы их наконец. У меня все атрибуты каждого качества "вес", "адрес" да и любого другого качества, сколь угодоно сложного, ХРАНЯТЬСЯ в одной таблице для всех(любых) объектов (по таблице на качество: мы описывам качество - система создает таблицу). Мы можем обратимся к системе  с запросом, "дай мне все объекты с весом "500, унции" и она( в результате очень простого запроса к этой ОДНОЙ таблице) вернет все указатели (OID) любых объектов с таким весом, будь то "яблоки, груши, столы, торты или клиенты с марса".

Я очень люблю ананасы ;)

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

Цитата

ИМХО Вы черезчур усложняете схему. Вот ситуация: один вес измеряется в граммах а другой - скажем в унциях . У меня это будет выглядеть так: яблоко1(200,"граммы"), яблоко2(500,"унции"). Но схема то не поменялась. А у Вас? Я что-то не могу понять, как она будет выглядеть (похоже должен появиться второй объект "вес", связанный через "унции" с "единицами измерения").

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

Код

-Яблоко  +Вес ---<210>-->[Значение]    | <грамм>    |    v  [Единица измерения]

Стрелочки со значениями, как и раньше - это направленные связи, а расположение Веса с плюсом под яблоком с минусом эмулирует показ оного соотношения, если его записать в XML, а именно: Этот Вес - подобъект этого Яблока. (Помните, я писал, что объекты, помимо прочего, можно выстроить в дерево?)

BTW, по ссылкам у меня тоже можно "гулять" в обе стороны.

Цитата

Наконец - так вы с чем спорите? - со моими построениями или с реляционной моделью?

На всякий случай повторюсь еще раз: Вес есть объект

Настрелял скринов для облегчения понимания.

Вот типичный объект из базы: http://www.crimaniak.com/oodb/demo/object.gif
Слева подобъекты, справа свойства. И того и другого может не быть.

Вот оодв админ предлагает мне вводить свойства, исходя из принципа наследования: http://www.crimaniak.com/oodb/demo/propselect.gif

Вот что делаем, если свойство обладает вариантами: http://www.crimaniak.com/oodb/demo/propvar.gif

Это сразу позволяет нам иметь такие вещи, как: http://www.crimaniak.com/oodb/demo/ref1.gif
То же самое относится к любому подобному свойству: http://www.crimaniak.com/oodb/demo/ref2.gif

Во всех других раскладах мы, конечно, тоже можем получить это же, но тут это не возможность - тут это фундаментальное свойство.

Так же легко проводить анализ на правильность. Пожалуй, с этим свойством нам делать больше нечего:
http://www.crimaniak.com/oodb/demo/good_data.gif

А тут после скрипта, который все это выколупывал из экселя, явно требуется доработка напильником: http://www.crimaniak.com/oodb/demo/bad_data.gif

To crimaniak
ОК

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

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

Давайте на примере веса... в моем необъектном понимании. Я уже писал, но придется растолковать. Только читайте до конца и внимательно. Есть домен "значения". Есть домен "единицы измерения". На этих двух доменах установлено отношение называемое "вес". Значения кортежей этого отношения могут выглядеть следующим образом ("100", "граммы"), ("200", "граммы"), (200, "унции"). Заметьте, я говорю не о свойствах "вес в унциях" или "вес в граммах", а просто о свойстве "вес". Сравним два последних значения (200, "граммы") и (200,"унции"). Естественно они разные, потому как у них разные значения  атрибутов, определённый на домене "единицы измерения".... я надеюсь понятие домен Вам знакомо). Когда мы говорим про "вес в граммах", или "вес в унциях", мы товорим о подмножествах отношения "вес", определенных исходя из значений второго атрибута "единицы измерения" (естественно, эти подмножества не пересекаются....). Где ошибка?

Теперь рассмотрим качество вес, как атрибут объекта "яблоко". Схема выглядит так: Оя{...,(200, "граммы"),...} Здесь я показываю, что объект "яблоко" определяется многими качествами, в том числе и сложным качеством "вес". ). Тем самым определяется существование нового отношения  и его кортежа (Оя, 200, "граммы") и практически в таком виде мы и храним из в реляционной БД.

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

Почему я назвал ваше определение связи смутным? Внимание, цитата!...из Вашего раннего

Цитата

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

Определите пожалуста, что Вы подразумеваете под этим "чем-то". Объекты? Взгляните на последнюю схему. Вес в данном случае - это отношения к "значению" с значением 210, или же это отношение к "единицам измерения" с значением "граммы"? Но если это и то и другое, то он уже пятиричен?... или он все лишь четверичен, но таки имеет неатомарное значение (210, "граммы")? Сам вес - это объект? Значит есть связь между объектом "яблоко" и объектом "вес" (они же связаны, в конце концов)....но эта связь не есть свойство, ведь у нее отсутсвует собственной значение... Или же вес - это не объект? Но тогда(третий раз спрашиваю) что это?

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

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

Цитата

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

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

Цитата

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

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

Цитата

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

Увы, если прочтение моих предыдущих писем ничего не дало, тут я бессилен. Тем более что я никогда значение не называл связью. Кажется, Вы заквотили соответствующий фрагмент в последнем письме, не прочитав его. Потому что там явно написано иное. Разжую, кстати, ответы на вопросы (вот не думал, что это кому-то придется явно объяснять). "Чего-то" к "чему-то"  там - да, как раз объекты. И связь является переменной для значения. А соотношение веса к яблоку - действительно, отличается от обычных свойств, и у него нет значения, значащим является его наличие. Потому что это соотношение типа "part of.." Оно очень важно, так что я сделал поддержку его в базе. "Человек может оперировать только с тем, что может выстроить в иерархию". Вернемся к весу и прожуем его еще раз. Объект есть набор его свойств. А набор свойств есть объект. Можно заявить, что "не каждая рыба - селедка", но фишка в том, что это делать незачем. Это усложняет и лишает гибкости. Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами. У него есть два свойства - значение  и единица измерения. Вес-набор свойств является частью яблока как набора свойств. Что я отразил на схеме. Каждое значение атомарно, каждое свойство троично. Объект так сложен, сколько свойств для него напихаешь. Все.

Буду закругляться, потому что реплики типа {Попробуйте изобразить схему для свойства "адрес" оставаясь  в рамках "третичности".} показывают не то чтобы непонимание, а абсолютное непонимание. Ведь даже на скриншотах, которые я постил, есть пример с конкретно адресом. И из примеров в целом можно нарисовать схему данных, которую я использовал для адреса в той базе.

отдельная заметка "To: All"

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

Теперь расскажу про подводный камень, на который можно наткнуться далее.
Итак, все работает. Возникло искушение еще более упростить схему и оставить одну таблицу. Таблицу свойств. Ведь если мы все свойства объекта записываем связями, то что остается в самой таблице объектов? Ни-че-го! Только уникальный ID. А зачем нам куча записей с уникальными ID? Достаточно будет счетчика, который будет инкрементироваться при создании нового объекта, дабы не шариться по базе с MAX(ObjectID)+1 в поисках следующего номера. И наступает полная ляпота. Например, такая вот:

s t value
- - ----------
1 1 Название
2 1 Вес
3 1 Яблоко1
3 2 210
4 1 Яблоко2
4 2 260

Или такая вот:

s t value
- - -------------------
1 1 Название
2 1 Вес
3 1 Часть от
4 1 Значение
4 3 2
5 1 Единица измерения
5 3 2
6 1 Яблоко1
6 4 210
6 5 грамм
7 1 Яблоко2
7 4 10
7 5 унций

Но - увы и ах! Так мы сделать не можем. Точнее, можем, но получим одну интересную проблему из области ИИ (в том плане, что там подобные грабли двно известны) - у нас нет точки отсчета. То, что у нас получилось, называется "сетевая модель данных". Как верно заметил кто-то из авторитетных, "сетевая модель - хороший способ потерять Ваши данные". В данном случае любой пользователь может создать абсолютную копию имеющегося графа, и у нас не будет никаких критериев, чтобы отличить одно от другого. Или немного отличающуюся копию... Таким образом, нам надо забить где-то на графе гвоздь, который там покажет, что вот оно - начало. В живых нейронных сетях таким гвоздем являются ощущения "хорошо - плохо организму". Мы можем запомнить ID Названия и дальше плясать от него, к примеру. Но это плохо. Я опущу долгие разборки насчет путей решения этой проблемы, но кратко вывод получается следующий: легче оставить таблицу объектов и добавить туда ParentID, превратив модель в иерархическую. Это добавляет нам быстродействия и избавляет от головной боли по поводу целостности данных, репликации и прочих аспектов. И, что для современной базы немаловажно, дает однозначное соответствие с XML форматом. Базу легко импортировать-экспортировать частями-"ветками".

Успехов, короче.

то Crimaniak
ОК!
Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов

1)
[QУОТЕ]схема данных должна отражать предметную область. Я привел пример и нарисовал для него схему данных. Вы изменили этот пример и я привел для этого случая другую схему данных[/QУОТЕ]

Я бы сказал "пришлось менять схему, что бы впихнуть ее в парадигму". У меня схема данных НЕ меняется. Что есть гибче?

2)
[QУОТЕ]Тем более что я никогда значение не называл связью[/QУОТЕ]

...из раннего...

[QУОТЕ]210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами[/QУОТЕ]

...и вдогонку...

Цитата

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

...а в следующем посте...

Цитата

Статью я не пересказывал, а с ней полемизировал.

Слов нет...

3)...о том, что Вы называете объектами
[QУОТЕ]Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами[/QУОТЕ]

Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты.

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

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

Вы же ставите знак равенства между "базовыми"(логическое понятие) и "примитивными"(аппартно-поддерживаемыми) типами. Я хотел бы обратить внимание на Вашу фразу из раннего

Цитата

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

(Кстати CHAR(12) уже есть сложный тип)

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

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

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

то Crimaniak
ОК!
Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов

1)

Цитата

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

Я бы сказал "пришлось менять схему данных, что бы впихнуть ее в парадигму". У меня схема данных НЕ МЕНЯЕТСЯ. Вопрос - что есть гибче?

2)

Цитата

Тем более что я никогда значение не называл связью

...из раннего...

Цитата

... .210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами.

...и тогда уж вдогонку...

Цитата

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

...а в следующем посте...

Цитата

Статью я не пересказывал, а с ней полемизировал.

...странно это все.

3)...о том, что Вы называете объектами

Цитата

Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами

Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты.

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

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

Вы же ставите знак равенства между "базовыми"(логическое понятие) и "примитивными"(аппартно-поддерживаемыми) типами. Я хотел бы обратить внимание на Вашу фразу из раннего

Цитата

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

(Кстати CHAR(12) уже есть сложный тип)

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

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

Взаимно желаю удачи

To crimaniak
Я извиняюсь, что влезаю в вашу дискуссию. Сразу скажу что не обладаю такими знаниями в области объектных баз данных. Но просто хочу отметить одно противоречие

Цитата(crimaniak @ 30.7.2002, 20:29)

Например, таких, что схема данных должна отражать предметную область.

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

class Единица
{
 AnsiString Value;
};

class Значение
{
 double Value;
};

class Вес
{
 Единица*   ed; //указатель на объект единица
 Значение*  val; //указатель на объект значение
};
class Яблоко
{
 Вес* value; //указатель на объект
};

То есть все сводиться к агрегатированию классов. При этом непонятно с весом. В реалиях вес у яблока  один, но он может измеряться разных единицах
Я бы поступил по другому.
class Вес
{
private:
double Value; // значение в базовых  единицах
public:
double GetValue(); //значение в тех единицах , которые мы хотим получить
AnsiString  Ed;      // единица ихмерения          
};
Здесь Вес - некое понятие, выделенное в класс, которое ведет себя в соответствии с определенными правилами, т.е если я в Ed - задаю единицу, я получаю соответствующее значение веса. Теперь внимание:
class Яблоко: public Веc
{
Цвет соlor;
Сорт sort;
....
};
Ну добавим еще для примера
class Стол: public Вес
{
Форма form;
}
Вместо агрегатирование используется наследование.
Я использую класс Вес не для создания объктов, а для наследования от него. т.е я выделил понятие Вес в класс и в то же время сделал так что чистых объектов "Вес" не существует.В С++ имеются способы наложить такое ограничение. Теперь как это я бы наложил на реляционную БД

Таблица Вес
ID                                                      
Value
ClassID                                  

Taблица Яблоко                      
ID  
Цвет
Сорт                          
ВесID

Tаблица Стол
ID
Формв
ВесID

Здесь не хватает только таблицы классов
Classes
ID
ClassName
ClassTable

Ну а далее все просто. Для каждого класса создается вьюер. Если предполагается работа с определенным классом, то открывается вьюер, где имееются все столбцы данного класса. GetValue() для веса может быть реализована хранимой процедурой. Если предполагается работа с заранее неизвестным классом(например при реализации принципа глобального каталога), окрывается базовая таблица, определяется к какому классу принадлежит данный объект  и соответственно обращение пойдет к таблице соответствующего класса(реализация полиморфизма - базовый класс преобразуем в производный) .  Совсем нетрудно написать компонент(я работаю с С++Builder), который  реализует данный механизм на автомате.
При этом, как показывает практика, не нарушается принцип нормализации данных и добавление новых классов происходит безболезненно

To Vyacheslav

Предупреждаю, что это в этом письме будет больше философии, чем программирования.

Вы верно заметили, что я в ходе объяснений использовал две разные схемы данных для "сложного" веса. Сначала я изложил ту, которая однозначно отображается на ОО язык, чтобы облегчить понимание, в последних же письмах я в табличном виде привел схему, которой сейчас предпочитаю пользоваться сам (ее же можно проследить в скриншотах). Как же так получилось с отображением? А очень просто. Есть бесконечное количество языков, при помощи которых мы можем отобразить предметную область. И это ничего не значит. (Поэтому, кстати, являются пустым звуком заявления типа "при помощи этой модели можно выразить ту модель". Ту модель можно выразить и палочкой на глиняной дощечке, но что это нам дает? Доказывает полноту этой модели? Но у нас нет недостатка в полных моделях.) А значащим является то, как много усилий мы потратим на описание нашего кусочка мира, и на поддержание его в адекватном состоянии. И значащим для конкретно этой заморочки (отображения первой схемы на ООП язык) является тот факт, что два разных языка вовсе не обязательно могут однозначно переводиться друг в друга, даже если они оба прекрасно описывают нужное нам множестно предметных областей.
И вовсе необязательно эффективное в одном языке решение будет таковым и в другом.
Теперь ближе к примеру. Вы утверждаете, что "Вес" как объект не отображает предметную область и не является объектом (или не обязательно является объектом) в ООП языке программирования. По крайней мере я так понял это: совсем необязательно чтобы по каждому классу предполагалось создание объекта
Теперь посмотрим на пример... Нет, теперь я не премину похвастаться, так как это позволит проиллюстрировать разницу в мышлении, ведущую к расхождениям. Итак, хвастовство: одно время в институте у меня была кличка "компилятор", потому что я мог, взяв Сишный текст, с ходу расставить на нем предупреждения и ошибки, которые выдаст компилятор, и для небольшой процедуры - написать ассемблер, в который она откомпилируется.  А вот теперь к примеру.
Я использую класс Вес не для создания объктов, а для наследования от него.
Но позвольте - как только мы начинаем думать о хранении информации, а не о проверке на корректность кода, эта разница превращается в абстракцию. Частью каждого объекта Яблоко является объект Вес, с которым мы работаем именно как с объектом, независимо от места расположения. Таким образом, тот пример, который "я бы поступил по другому", полностью аналогичен первой данной мною модели для сложного веса. Там тоже в каждом объекте яблоко вложен объект вес, и доступ к значению и единице измерения производится через этот вложенный объект. Заметьте, я Вас за язык не тянул. Вы сами предпочли завести класс "Вес", тем самым реализовав наличие объектов "Вес" и согласившись с моим утверждением, что "Вес есть объект". А что до "наследования" vs "агрегатирования", так в и базе можно реализовать совершенно аналогичные механизмы видимости и размещения, хотя это не будет оптимальным решением (все-таки модель это другая, и решения тут другие). При чем тут мое хвастовство? Для иллюстрации одной фразы, (с) К.П.: "Зри в корень!". Увлекаясь жонглированием "агрегатированием", "доменами" и т.д., легко забыть их физический смысл и потерять общность явлений, а то и прийти к неправильным выводам.
Вернемся к необязательности наличия объекта при наличии класса. Увы, и тут Вы неправы! Создатели Явы, которые вознамерились довести ООП концепцию до конца, и преуспели в этом больше, чем кто-либо другой, давно уткнулись в такую необходимость. Результат: java.lang.Class. Каждый класс есть объект, вот так. У меня ведь этот вывод тоже не по щучьему велению появился - как я уже писал, я реализовал сайт с промежуточной моделью, и трудности, которые там были, и обдумывание путей решения привели меня к тому, что есть.
Вот еще один пример пагубных последствий отсутствия привычки смотреть в корень. Мне пишут:

Цитата

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

 Человек сказал последнее слово и довольно улыбается, но он забыл посмотреть в корень. Он думает, что пять операций INSERT - это в пять раз неэффективнее, чем одна операция INSERT. А мы посмотрим в корень и сделаем выводы. Итак, что у нас существует реально? То есть физически. У нас существует таблица, являющаяся набором полей, и ряд индексов, с которыми, собственно, и производится основная работа. Настолько основная, что при выборке данных в случае наличия индексов для всех выбираемых полей к собственно таблице доступ не производится вообще. Независимых, кстати, индексов, по одному независимому индексу для каждого поля (или группы полей). Доступ к таблице - самая быстрая операция, особенно в случае строк с фиксированной длиной (А в моем варианте базы все свойства, не требующие поля с переменной длиной строки, хранятся именно в фиксированных строках, чего нельзя сказать о варианте со неатомарными свойствами - там достаточно одного varchar на свойство, чтобы загнать все соседние INT в таблицу с переменной длиной строки). Более интеллектуальной и длительной операцией является обновление индекса, потому что именно при этой операции проверяется корректность данных и, возможно, балансировка дерева. Кроме того, когда мы рассматриваем пакетные вставки, разница растет катастрофически, потому что вставки в таблицу обычно (зависит от фрагментации) идут одна за другой (последовательно в файле, имеется в виду) и пишутся в конце транзакции в один-два приема, а вот шарясь по индексным файлам, приходится читать и изменять случайные их блоки, что предотвращает кеширование индексов.
Итак, посмотрим на ситуацию на более низком уровне. INSERT с пятью полями: интерпретация SQL, пять вставок индексов, вставка записи в таблицу.
Пять INSERT по одному полю - пять интерпретаций SQL, пять вставок индексов, пять вставок полей в таблицу. В случае наличия прекомпилированных запросов - одна интерпретация SQL, пять индексов, пять записей.
В чем разница? Четыре вставки в таблицу, самые быстрые операции. Самая сложная операция - обработка индексов - производится одинаковое количество раз.
 Конечно, я тут чуть схитрил в подсчете. В случае атомарных полей операций с индексами получается больше, хотя самих индексов - меньше. Но теперь вспомним еще одно обстоятельство, на которое я уже обращал внимание. В правильной реализации объектной базы нет места SQL. Нам незачем компилировать один язык в другой язык, потом разбирать другой язык и только после этого его выполнять. Получая проигрыш в быстродействии и ограниченную функциональность к тому же (ведь применение SQL сильно нас ограничивает - мы не можем получить recordset с объектами разного типа). Правильное решение - делать разборку своего языка в алгоритмы работы с данными через низкоуровневые библиотеки, используя разные варианты BTREE. В результате будет быстрее и с возможностью получения коллекций любых объектов без снижения скорости. При этом все предыдущие рассуждения насчет эффективности вообще теряют силу, и выясняется, что реализация на этой основе атомарных свойств проще по коду при одинаковом быстродействии.

 На этом откланяюсь - пора домой.

to Vyacheslav

Предыдущий пост, обращенный к Вам, еще раз убеждает меня, то Объектное мышление не только полезно, но и вредно.

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

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

Следующий этап возникает когда мы запихиваем информацию в компютер. Эта железяка так устроена, что понимает только числа. Поэтому перед тем, как засунуть значение сущности в компютер, мы должны закодировать его. Кстати наш мозг устроен слега также, и ("0.1", "кг") в принципе является кодом, а коды ("0.1","кг") и ("100"."гр") образно говоря представляют одно и то же значение... по крайней мере для обученного человеческого мозга.

Изходя из вышесказанного, модель данных должна позволять описывать данные с трех сторон - 1) объекты 2) субъективное восприятие 3) железо.

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

Но вот когда заходит речь о субъективных сущностях то наблюдается прямо противоположная картина. Если мы описываем ее как объект, то что мы имеем? Вместо того, что бы идентифицировать сущность по ее явно заданному изначально конечному значению ("0.1","кг"), мы берем и присобачиваем к ней еще одно значение - значение OID. В этом отсутсвует какой-либо смысл, более того - если это называть моделью, то это неправильная модель. А единственая причина, по которой мы это делаем заключается в том, что чистая объектная парадигма и языки которые ей следуют, не дают нам другой альтернативы. "Любая переменная является объектом", "любой объект имеет OID" и точка.

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

К чему я это? Собствено к тому, что Вы сказали "реалиях не  может существовать отдельно объекта "Вес". Согласен полностью - "вес" существует только в людских головах. Почему вы его описываете как класс? Да потому, что нет альтернативы.  А по поводу
[QUOTE]Частью каждого объекта Яблоко является объект Вес, с которым мы работаем именно как с объектом, независимо от места расположения. /QUOTE]
ИМХО это неверно, т.к. в данном случае OID есть только у объекта "яблоко", а то, как это храниться в системе, так это к модели ни имеет никакого отношения. Пусть "вес" храниться как объект, но это не значит, что мы должны оипсывать его как объект.

ИМХО надо отличать модель от системы, реализующей эту модель. Попробую пояснить на примере. Вот взять тот же ... хотя бы MS SQL Server. Без сомнения он реализует (более-менее полно ) реляционную модель и ничего объектного в SQL-е нет. Но сама то система фактически является объектной: каждая таблица (в том числе и таблицы каталога), или вид, или что-то еще  - это уникальный объект, имеющий состояние, интерфейс, класс, и тп. Но все эти объекты системы не делают  реализуемую системой модель объектой. Случай с Java интереснее - это объекная система реализующая объекную модель, т.е. объекты системы(в тч классы) могут быть описаны моделью реализуемой этой системой....ну и слава богу (на самом деле идея, что класс можно рассмаривать как объект, лет на 20-30 старше чем Java) Дело в том. что когда я создаю некую схему данных, мне условно говоря по-барабану, будет ли информация об описываемом классе храниться в системе как объект или не будет (конечно если в схему данных не входит сущность "класс"). Для схемы данных важно только то, что такой класс есть. И мне гораздо интересней,как я могу описать сущность входящую в схему данных сущность "вес". В общем, утверждать "храниться как объект - значит является объектом", ИМХО неверно.

5)
...и наконец а буду ли я делать все пять полей в записе "адрес" индексируемыми?

Цитата(Guest @ 31.7.2002, 22:35)

To Vyacheslav Вы верно заметили, что я в ходе объяснений использовал две разные схемы данных для "сложного" веса.

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

Цитата

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

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

Цитата

Вернемся к необязательности наличия объекта при наличии класса. Увы, и тут Вы неправы! Создатели Явы, которые вознамерились довести ООП концепцию до конца, и преуспели в этом больше, чем кто-либо другой, давно уткнулись в такую необходимость. Результат: java.lang.Class. Каждый класс есть объект, вот так.

Я как то привык смотреть на классиков, а не на конкретные реализации.Тем более что java я не знаю. А в ООП  тоже допускается рассматривание класса как объекта. Данная концепция реализована Smalltalk и CLOS. Но в этой концепции класс рассматривается как объекта Метакласса - класса классов. В чистом С++ такого понятия нет но  в Builder & VCL реализована подобная конструкция конструкция
TMetaClass* Class = classid(TMyClass);
но это не имеет никакого отношения к объекту данного класса
TMyClass* MyClass = new TMyClass;
Думаю, что в java то же самое. Так что сославшись на java, Вы слукавили.   Поэтому мысль класс - это объект не нова. Но к данному вопросу отношения не имеет. У меня это факт нашел отражение в наличии системной таблицы Classes. Я утверждал, что не создаю объектов данного класса.  Возможности наложения  данного ограничения заложены в ООП : клиентами класса могут быть объекты и субклассы, но но не предусмотрен обязательное присутствие того и другого.  В С++ я могу наложить такое ограничение средствами языка.Предполагаю, что такие возможности имееются и в других языках ООП  

Цитата

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

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

Цитата

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

"Может ли ветер в голове испортить прическу?" Еще раз с самого начала. Я приводил в качестве примера схему, где вес является атомарным атрибутом, и это выглядело так:
[Яблоко1] ----<210>---> [Вес] <----<260>---- [Яблоко2]

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

По второму абзацу - я про Фому, а мне про Ерему. Если внимательно почитать этот тред, станет понятно, что тут разногласия именно по способу хранения. Чтобы не повторяться, только замечу, что я могуполучить "Вес" как имя класса. Не во всех языках, естественно.

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

Цитата

Не думаете же Вы, что  я влез в эту беседу из теоретического интереса.

Почему бы и нет?

Цитата

К принятию такого подхода я никакого отношения не имел . Оно было принято на основе многомесячного исследования группы аналитиков.

Ужас какой!! Еще и денег, наверное, много взяли?

Напоследок еще один пример, который подскажет, зачем нужно то, что сделал я. Типичная ситуация изменения схемы данных: Вот у нас уже есть база с одним миллионом яблок с атомарным весом. И "вдруг" потребовалось добавить единицу измерения. (Чтобы сделать ситуацию более реальной, поменяйте "единицу измерения" на "валюту", и остальное соответствующе). Что мы будем делать в случае реляционной таблицы? Правильно, Alter table по миллиону записей. Что мы будем делать в варианте моего оппонента? Правильно, опять Alter table по миллиону записей. Правда, его, видимо, будет делать система (см. конструктор MS Access).
И только в моем варианте нам надо добавить один объект. Гибкость, ребята, гибкость! XML абсолютно неэффективен и дико избыточен, однако под него сейчас перетаскивают все подряд. По той же причине.

Реплика...

ALTER TABLE по миллиону записей - это конечно ужасно. Но и в Вашем случае, уважаемый Crimaniak, добавлением одного объекта ИМХО ну никак не обойдется. Поскольку мы меняем единицу измерения для миллиона УЖЕ существующих значений, то Вам по-крйней мере потребуется вставить в таблицу связей миллион записей со значением единицы измерения (например "кг."). Кроме того, поскольку Вы меняете схему Вам придется обновить по крайней мере еще миллион записей со значением веса в той же таблице. Тоже нехило;). Или я опять ошибаюсь?

Цитата

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

Я таких примеров не понимаю. Т.к это глупый подход.При правильном подходе  добавление единицы измерения никак не может повлиять на класс Яблоко. Вес не может меняться в зависимости от единицы измерения.  1000г =1 кг
Добавляется не поле, а экземпляр класса Единца Измерения. То же самое и с валютой. Не будете же Вы  бездумно создавать систему.
Вы так ничего и не поняли.  При нормальном  подходе таблицу перебивать не потребуется,, так как   таблица предназначена для хранения ДЕЛЬТЫ - то есть тех полей, которые отсутствуют в предыдущем базовом классе.    
Теперь мой пример было 1 миллион заказов(класс Заказ).  С некоторого момента ввели еще одну графу  (например налог с продаж). Сами понимаете, что все для предыдущих заказов НСП  не нужен. Я создаю класс Заказ1, производный от Заказ. Это выглядит: к первой создается еще одна таблица с одним полем, которого не хватает
Заказ    Заказ1
ID         ID
....        НПС
           ЗаказID

Причем в первой таблице так и осталось 1000000 записей, во второй ноль, пока не начнем  создавать Заказы1.
Как объединяются поля двух таблиц - объяснять надеюсь не надо  или  на всякий случай надо
select * from Заказ з, Заказ1 з1  where ЗаказID=з.ID  
А в программе  у меня это выглядит так - просматриваем старые заказы - ядро системы берет только одну таблицу - поля НПС нет, натолкнулись  на Заказ1 - сразу появится поле НПС.

Цитата

Ужас какой!! Еще и денег, наверное, много взяли?

Ой и не говорите. Правда в качестве зарплаты. Я работаю в софтверной фирме и приходится содержать свой штат аналитиков.

Цитата

Я таких примеров не понимаю. Т.к это глупый подход.

Наоборот, очень хороший пример оказался, показательный. Вы ошиблись насчет модели Евгения, он ошибся насчет моей модели.

Цитата

Вы так ничего и не поняли.  При нормальном  подходе таблицу перебивать не потребуется,, так как   таблица предназначена для хранения ДЕЛЬТЫ - то есть тех полей, которые отсутствуют в предыдущем базовом классе.     Теперь мой пример было 1 миллион заказов(класс Заказ).  С некоторого момента ввели еще одну графу  (например налог с продаж). Сами понимаете, что все для предыдущих заказов НСП  не нужен. Я создаю класс Заказ1, производный от Заказ.

 Я-то понял, а вот Вы - нет. Я совершенно согласен насчет нормального подхода, но вот модель Евгения этого не предусматривает, так как он продолжает в упор не понимать смысл идеи и пугает нас необходимостью alter table, да еще и миллионом insert into. А вот мой вариант реализации - это и есть "нормальный подход" с вашей точки зрения, так как у меня все так и происходит. Мы Делаем новый объект сложносочиненного веса, делаем бывший вес его потомком и добавляем объект для единицы измерения. При этом старые объекты не имеют единицы измерения, что код, который нам в любом сдучае надо учить новый реалиям, воспринимает это как единицу изменения по умолчанию, а новые создаются уже с единицей.
Причем заметьте - реализация остается гибче, чем объектное представление. У Вас происходит такое неприятное явление, как накопление мусора. Так как в результате получается два класса там, где нам нужен один. А потом три... и так далее. Структура конечного класса отличается от того, что было бы создано, будь вес изначально сложным. (Это означает, что рано или поздно придется производить сборку мусора - переписывать код с нуля). И у нас возникают некоторые проблемы. Теперь нам нужен + для старого веса и нового, или приведение старого у новому. А что надо сделать, если мы хотим старый_вес+=новый_вес? Отвечать не надо. Я знаю, что эти все проблемы решаемы. Но! На физическом плане их не существует. Они - лишь следствие решения бороться с изменчивостью схемы данных путем наследования, которое изначально было придумано не для того.

Слегка дурацкий разговр получается. Я через пост пишу о том, что модель не имеет ничего общего с реализацией и с вопросами производительности, а уважаемый Crimaniak точно с такой же частотой начинает вещать, что де его система будет работать быстрее.  Так вот - я со всей ответсвенностью заявляю, что в моей  МОДЕЛИ  ALTER TABLE для таблицы с миллионом записей делается мгновенно . А SQL и реляционная модель - это совсем не одно и тоже.

И все же... раз уж зашла такая пъянка про производительность.... Ну ведусь я у своего уважаемого оппонента.  То что некоторые мои вопросы остаются неотвеченными... или например рассуждения о том, что вставка одной записи это более сложно, чем вставки пяти записей...ГЫ-ГЫ...  а что если там нет varchar'ов и не таблица не индексируется по всем полям?...но это благололучно проехали. ИМХО и так ясно.

Далее... ну предположим, что система часть информации о весах описывается старой схемой, а часть  - новой. Теперь мы хотим получить объект с весом "20","кг". Вы попробуйте изобразить такой запрос к системе хранения, что бы он обновременно брал и те и другие значенния. ИМХО - если получиться, то очень хитро. Дело в том, что стрелочки в схемах идут по-разному и, соотвественно JOIN'ы в запросах обращающихся к данным должны также идти по другому. Но насколько я понял, это тоже фигня. Там еще оказывается код есть .

(у меня на кухне ИИ есть. В холодильнике. Он мне анекдоты на ночь рассказывает)

А как же быть со следующим? (из Вашего раннего)

Цитата

Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до.

Ну здесь то уж точно придется переделывать старые "объекты"  (Пусть их даже МИЛЛИОН!) в новую схему? Иди нет? Что то там "по-умолчанию будет?

Вооот!....и наконец мы добрались до JOIN'ов (я просто уверен, что эта тема будет опущена ). Перестройки схемы данных - это явление сравнительно редкое, но вот JOIN'ны встречаются спошь и рядом. Любая более-менее сложная опреация поиска или выборки скорее всего не обойдется без JOIN'нов. Но в том, что предлагается Вами, уважаемый Crimaniak, это просто чума. Я прикинул ...возмем тот же вес...  для того, что бы найти "20", "кг"
потребуется сделать не менее трех...даже четырех... нехилых JOIN'ов с предварительной выборкой из двух горячо любимых Вами таблиц... А что будет если надо найти адрес по пяти полям (причем использующих в условии оператор OR)? ИМХО именно поэтому вы и не любите сложные значения и предпочитаете все веса выражать строго в килограммах.

Сославшись на Дейта и на Конноли, могу утверждать, что JOIN является самой трудоемкой и доргостоящей операцией. Затраты на выполнения запроса зависят от числа JOIN'ов приблизительно по экспоненте. А у вас любая выборка без него (причем в больших количествах) не обходиться.

Во-первых, насчет индексирования. Не знаю, как у других, но моя практика показывает, что никогда нельзя заранее точно сказать, для каких полей индексы потребуются, а для каких - нет. А рассмотрение моих текущих проектов показывает, что подавляющее число полей - индексированы. Отсюда мы приходим к очень простой практической рекомендации: индексировать все поля, кроме разве что blob/text, потому что снижение производительности в результате наличия лишних индексов не идет ни в какое сравнение со случаем их отсутствия там, где надо. А если сделать только необходимые индексы, то по мере развития модели такая ситуация возникает. Причем, как правило, сначала эти тормоза незаметны, но с ростом базы начинают оказывать все большее влияние, пока программист не вынужден садиться за лог медленных запросов и смотреть, где какой индекс он забыл добавить. Таким образом, решение с полностью индексированной базой просто экономически выгоднее.
Во-вторых, насчет joins. Вопросы насчет реализации снимутся, если внимательно прочитать предыдущие письма - я там давал конкретные примеры, на которых видно, как все работает. В данном случае это будет выглядеть так.
Первый элементарный случай:
SELECT яблоки->\свойства\вес FROM \яблоки\%
Второй сложный случай:
SELECT яблоки->\свойства\вес\значение, яблоки->\свойства\вес\единица_измерения FROM \яблоки\%
Мы даже можем сделать так:
SELECT яблоки->\свойства\вес, яблоки->\свойства\вес\единица_измерения FROM \яблоки\%
(если захотим обеспечить толерантность старых запросов. но это неправильно.)

Цитата

Далее... ну предположим, что система часть информации о весах описывается старой схемой, а часть  - новой.

 Этот фрагмент я заквотил, так как он иллюстрирует Ваше продолжающееся непонимание моей схемы. Объясняю на пальцах: у нас нет ситуации, когда часть данных хранится по старой схеме, а часть - по новой. Эта ситуация возникает только у Вас, и избавиться от нее Вы можете только при помощи ALTER TABLE. Мне же достаточно произвести изменения в паре объектов - и все яблоки приобретают вес по новой схеме. Единственное отличие от случая, когда мы создали бы сложную схему сразу - у нововведенных атрибутов есть значение по умолчанию (второй запрос выдаст NULL в единице_измерения для старых яблок), но такую схему часто имеет смысл предусмотреть еще при проектировании, так как это экономит место в базе за счет очень малого изменения кода.

Насчет быстродействия же - советую читать не только классиков, но и что-нибудь поновее, чтобы не говорить ерунды насчет экспоненты. Очень рекомендую посмотреть сайт http://www.innodb.com/ Я проверял - дело обстоит именно так, как там написано. И это правильно. Попробую и тут заранее пояснить на пальцах: про поиске по нескольким индексированным полям поиск происходит по индексам, и базе совершенно безразлично, к одной таблице относятся эти индексы или к разным, потому что все индексы независимы. У нас добавляется поиск еще в UNIQUE(INT) индексе на join, но и тут экспоненты никак не получается - штука, которая у нас получается, называется логарифм.

Цитата

Таким образом, решение с полностью индексированной базой просто экономически выгоднее.

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

Далее. В своем последнем сообщении я говорил, не про то, как вы пишите запрос в СВОЕЙ системе, а про то, во что он преобразуется СИСТЕМОЙ при обращении к используемой (в нашем случае реляционной, что-то другое я обсуждать не буду) СУБД. Цитата (из вашего раннего)

Цитата

Получилось достаточно удобно, типа $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], а потом выполняется.

В последнем, ОТТРАНСЛИРОВАННОМ запросе связываение по JOIN'у выполняется два раза. Навсидку для каждого поля "сложного своства" связывание по JOIN'у будет выполняться два раза, т.е при поиске по пяти полям эта операция будет выполняться десять раз.Индексы-индексами, но связывать все-равно то придется.

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

Цитата

Первый элементарный случай: SELECT яблоки->\свойства\вес FROM \яблоки\% Второй сложный случай: SELECT яблоки->\свойства\вес\значение, яблоки->\свойства\вес\единица_измерения FROM \яблоки\% Мы даже можем сделать так: SELECT яблоки->\свойства\вес, яблоки->\свойства\вес\единица_измерения FROM \яблоки\% (если захотим обеспечить толерантность старых запросов. но это неправильно.)

Последний запрос меня не убеждает - 1) там явно используется две разные схемы хранения веса (это мне совсем не нравиться..... я уж ALTER tABLE один раз воспользуюсь, что бы потом мозги не парить насчет "а как там" ) и 2)  интересно во что он  оттранслируется?

Наконец- повторяю вопрос
А как же быть со следующим? (из Вашего раннего)

Цитата

Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до.

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

1. Подсчет "навскидку" количества joins - неправильный. В том конкретном примере есть такая конструкция, как ...\\%\\% - подумайте над этим. (Да, процент означает именно то, что он означает в LIKE).
2. Я потерял надежду объяснить конкретно Вам, как это все работает. Если интересно понять, а не спорить со мной - возьмите листочек бумаги и опять же начните думать. За исходние данные можно такой факт, как то, что в моей схеме и в случае с яблоками, и в случае с ценами за период схема данных для всех объектов аналогично меняется изменением одной-двух записей в базе, при этом ничего перелинковывать не надо - тот же объект-цель меняет адрес.

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

Ээээхххх
а мне предстоит реализовать эту самую объектную прослойку для РСУБД.
......

Ну что, достаточно напугали автора топика?
Там где - то В НАЧАЛЕ статья какая-то прозвучала. По моему полный порожняк. Я вот на Cache пробовал что-то делать, мне не понравилось. Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

Цитата(Oleg @ 26.7.2003, 10:13)

Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

Нельзя ли поподробнее?
Как проводилась интеграция?
А то уж слишком категорично звучит.
Любая вещь, если сделана неправильно, будет плохо работать...

Цитата(Oleg @ 26.7.2003, 10:13)

Я вот на Cache пробовал что-то делать, мне не понравилось. Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

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

Да ... чур эти ООБД ... почитал и понял - лучше то что проверено временем и работает, а не то что сулит выгоду на словах ... уж слишком все это громоздко. ИМХО через чур все это мудрено

Adminlion

Хороший "инженер по знаниям" и из XML, Фокса или MySQL такую объектную базу состряпает, что и не снилось. Утрирую конечно... Но Объектность Оракла не означает, что любая объектная модель реализованная на нем будет правильно отражать предметную область и быстро работать. Тут не программировать нужно уметь, а знания структурировать. )) Хотя и все вместе не помешает.
Так, что без фанатизма пожалуйста.

Fantasist

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

crimaniak

Фактически у вас три поля или реляционных таблицы, связанных по уникальному индексу
Или в виде дерева, связанные через Parent.

Объект<-Вес<-ЕдИзм
Стол 20 кг.
Стул 10 кг.
Дом 10 т.

Таблица задает жеское соответствие между полями.
А вот ваш вариант

(ID, Имя и ParentID) + (ObjectID, TargetID и Value.)
Такого жеского соответствия не задает. Сравните

Объект<-{Ручка,Стол,Дом}
Физ.признак<-{Вес,длина,ширина}
Ед.изм.<-{грамм,кг,центнеры,тонны,фунты...}

Стол1->Вес1, 20 (а чего?)

Чего-то недоговариваете ;)

Вот конкретная разработка:
http://www.garret.ru/~knizhnik/databases.html

Для некоторых целей довольно пригодные штуки

Cache - пример ОО БД