Смешались в кучу кони, люди :)

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

2)Я утверждаю(еще раз), что я ничем не жертвую. Оговорюсь - то, что я предлагаю, не есть конкурет систамам ОО-програмирования. Объектно-ориентирванные системы управления РБД есть инструмент, 1)позволяющий описывать моделируемую предметной области, и 2)среда согласовооного существования информационных объектов, соответсвующих этому описанию 3) механизм, позволяющий изменять состояние этих объектов и получать данные о их состоянии. Мне не нравится то, что мы должны описвать данные,хранящимися в таблицах, как набор таблиц. Мне не нравиться то, что мы должны управлять этими данными, используя операции над таблицами. Я хочу показать, что есть иной путь описание и управления данными, хранящимися в таблицах, причем сами таблицы (схема данных на уровне хранения) остаются практически без изменений. Поэтому совершенно уместно следующее сравнение: объектно-ориентирванные системы управления РБД настолько же менее эффективные по сравнению с традиционными РСУБД, насколько, скажем, С++ менее эффективен чем С (во всех аспектах, в т.ч. эффективность использования труда программиста).

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

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

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

В порядке FIFO, если не возражаете...

2 Дмитрий Мыльников (28.08.03)

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

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

>>Ты видел когда-нибудь что из себя представляли самые первые РБД?

Не видел, только читал. Сильная весчь, между прочим

>>Да и в чём основная суть табличного хранения и реляционной модели с точки зрения компьютера?

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

>>А в том, что в изначальной модели размер записи в таблице фикисированный, что позвляет сразу перемещаться на выбранный номер записи.

Вот это вообще вышак :). Все мои предыдушие распинания про адресный и ассоциативный доступ к данным прошли мимо. Совсем...... Какой-такой номер записи в таблице? С этого места можно поподробнее плиз?... Нехай местный народ поразвлекается.....

>>То есть, мы не прсоматриваем весь фал данных от начала к концу, а используя прямой доступ к файлу перемещаемся в нужное место.

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

>>Формальный механизм работы с данными? Да, согласен, формальный. Но сам по себе этот механизм уже есть определённый способ моделирования реальности.

Реляционная модель - это модель данных! и к реальности она имеет такое же отношение как орфографический словарь к роману за жисть :)

>>А Вы предлагаете этот механизм нагрузить сверху ещё одним механизмом.

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

>>В чём прелесть ООП? В том, что там, если всё делаеться согласно исходной модели, объекты не просто хранят данные, но ещё сами умеют их правильно обрабатывать
Супер-супер! Волга впадает в Каспийское море.... Я же не против, я только за.

>>В вашей же схеме мы опять по сути разделяем данные объектов, кторые хранятся в РБД и методы обработки этих данных. Такое решение может быть допустимым как некий компромис, но не более.

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

>>Кстати, я вашей модели я не уловил каким образом опиясывается "поведение" средсвами РБД? Состояние - понятно, связи - тоже понятно. А поведение? Особенно если учесть, что вы постоянно ссылаетесь в своей работе на манифест, в котором как основа утверждается использование непроцедурных языков. :) Я вот так и не смог придумать способ описать поведение на непроцедурном языке. Может быть разъясните мне, тёмному?

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

Для c127
Спасибо большое! наконец услышал что-то умное!!!!

*) ...т.е. o={OID,a,r} необходимо заменить на o=(OID,a,r).

Согласен...

*) определение <0>. Элемент r нельзя определять как множество, иначе будут проблемы с одинаковыми значениями: множество {1,1,1} есть просто {1}. Возможно это же касаетя элемента a, но тут я не уверен, не понимаю, что в данном случае понимается под именем. Самое простое – перейти от множеств к спискам. Но по-моему лучше объединить a и r в множество пар: x={(a1,r1),…,(an,rn)}, где имя уникально по крайней мере в пределах одного объекта. Тогда объект это o=(OID,x). Определение схемы в остается аналогичным данному в статье: Schema:x|->{a1,…,an}.

Буду думать...

*) “Теория реляционных БД предполагает, что для обеспечения эффективного хранения данных (что подразумевает их целостность и непротиворечивость) , эти данные должны быть нормализованы [8,9,10].”. Тут Cat2 уже говорил, и я присоединяюсь, что требование нормализации данных (т.е. соблюдение всех нормальных форм одновременно) не следует с необходимостью ни из требования их эффективного хранения, ни из требования целостности и непротиворечивости, ни тем более из реляционной модели.

Ребяты! Ё , ну есть же в теории нормализация.. В Майере это ж есть, а там только теория. НУ прям не знаю как эту мысль выразить... для чего ж это надоть то, а? Буду думать :)

*) соотношение <7>. Если это соответствие есть изоморфизм, то можно использовать обозначение изоморфизма, будет проще и понятнее.

Наверное,да...

*) На стр. 3: “Предполагается, что возможность, позволяющая описать объектную переменную и задать множество значений отношений {r1,r2….rn}, не может быть выражена в терминах реляционной модели данных и, следовательно, ортогональна ей.” Необходимо сказать более подробно о статусе этого утверждения, например что это аксиома. Тем более, что в статье оно повторяется еще по крайней мере трижды: на стр. 6,7 и косвенно на стр.9: “Окончательная структура данных, которая возникнет в процессе объектной привязки, выйдет за рамки реляционной модели данных (собственно, это и является целью наших построений).“ Последнее ставит под сомнение, что изначально предполагалась аксиома.

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

*) “Крайне важен тот факт, что предлагаемая формализация однозначно определяет способ, позволяющий представить информацию, описывающую множество O объектов вида <0>, в терминах реляционной модели данных.” Нет доказательства. К тому же это неверно, таких представлений может быть несколько, например всякие ненормализованные, да и нормализованных наверное может быть несколько, ведь нет теоремы о единственности нормализованного представления данных. Возможно имелось в виду, что существует единственный оптимальный способ представления, но тогда нужно доказывать соответствующую теорему. Возможно в данном случае вместо “однозначно определяет” лучше сказать: “определяет естественным образом”.

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

*) В статье встречается несколько утверждений, аналогичных двум предыдущим, к которым непонятно как относится: то ли как к теоремам, то ли как к аксиомам, то ли как к разъяснительным и не несущим формальной нагрузки.

Можно поконкретней?... а то там много всяких утверждений...

*) Вместо словосочетания “существует функциональная зависимость” по-моему лучше использовать “существует функция” или “ существует отображение”

Конечно....даже потому, что так короче ;)

*) Непонятно как записывается наследование классов на уровне храненния.

Мне кажется, в описании каталога (3) на этом останавлявался. Таблице ISA содериж полную информацию о наследовании. Только она содержит избыточную информацию, котррая позволяет вытащить информацию о потомках (предках) класса одним запросом. На самом деле я не настаиваю, что именно так должно быть, просто ИМХО это важнее, чем дерево наследования, представленное в чистом виде.

*) Непонятно как записываются методы на уровне хранения.

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

Ну вот взять, скажем, T-SQL. Там есть пользовательская функция. Когда мы ее используем, мы не думаем, есть ли там внутри последовательность вычислений, некий алгоритм, или это будет простой SELECT с параметрами. И здесь тоже самое, только речь идет об атрибуте.

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

2 Дмитрий Мыльников (30.082003)

>>Что получится в предлагаемой U-gene системе? Получится, что данные одного объекта будут разнесены по разным таблицам. То есть, чтобы получить данные одного объекта серверу или приложению (смотря где будет происходить "сборка") придётся проделать достаточно много операций. И всё для чего? Для того, чтобы было удобнее хранить? Но это вопрос спорный. Чтобы было удобнее описывать модель? А чем неудобна собственно ОП?

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

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

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

>>И не надо путать "строгое математическое описание" и реальные РСУБД.

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

>>Хотя, возможно, это разный взгляд на вещи теоретиков, которым важно именно "строгое мат. описание" и практиков, которые потом вынуждены придумывать как при реализации конкретных проектов выйти за рамки этого "строгого мат. описания", которые не позволяют решить поставленную задачу. И, что интересно, при выходе за эти самые рамки "строгого мат. описания" решение получается гораздо эффективнее, чем если пытаться всё сделать согласно теории.
Живо впоминаются десятилетней давности (или даже более того) обсуждения о том как оптимизировать код на ассемблере. Типа "я в центре цикла иногда по условию на конец перехожу и на 5% быстрее получается". А сейчас ляпнут DO...WHILE и хорошо. Я это к тому, что если бы эффективность было настолько важна, все до сих пор пользовали бы только ассемблер. А теория - это ..мммм.... формальное обоснование стандарта... типа значит того самого DO...WHILE , которым сейчас все пользуются

Для Дмитрия Мыльникова
Какую то кривую ссылку дал

О первой экспериментальной реляционной СУБД - СИЛЬНАЯ ВЕСЧЬ

Для vdimas

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

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

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

Во-во! Фактически речь идет о том, что двоичная структура должна соотвествовать машине Фон-Неймана. Но мои объектам этого не надо - им эта машина для...мммм... функционирования (непосредственно) не нужна.

И наконец
Для Дмитрия Мыльникова

>>И так мы постепено придём к тому, что вопрос нужно ставить не о том, "можно ли отобразить объекты на реляционную модель?"....

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

>>... а о том, что необходимо разработать удобный способ описания объектной модели, чтобы он позволил работать с объектами так же, как реляционная алгебра позволяет работать с реляционной моделью.
Соответсвенно, следующим шагом будет разработка некоего языка, подобного исходному SQL, но для объектной модели. Кстати, судя по имеющимся на сегодняшний день наработкам, в том числе и по работе уважаемого U-gene, реляционная модель должна быть частным случаем объектной модели, а язык SQL как бы частнм случаем этого нового языка (назвать можно например OML - язык манипулирования объектами :) ).

Да...мыдысынскый факт.... :) ИМХО мой пост о том, что объектная модель - это химера... остался непрочтенным :) . Не будет объектной модели! ООП есть, это средство, а модель данных - это цель.

2 Andy753

А Вы, батенька, приколист

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

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

Скажите правду, Вы Выше 10 топиков поднялись? :)

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

И самое главное - надо думать, перед тем как писать (ну хоть немножко!), а то так смешно, что аж обидно...

2 funikovyuri

Ссылки на аналогичный самокат, изобретенный ранее, предоствавьте пожалуйста. :) Оченно интересно, вдруг я что-то пропустил? Попусту болтать здесь многие горазды, хочется чего-нить поконструктивнее