Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 54 55 56 57 58 [59] 60 61 62 63 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Андрей Леонидович
не существует ни одного "официального" формализованного описания РМД

Не надоело эту ерунду повторять? Ваше нежелание учиться уже даже не смешит.
Андрей Леонидович

Просто в "реляционной теории" используется более изощренная демагогия:
Где же она используется, если по вашему никакой "формализованной теории" просто нет? Где ж вы ее вычитали? Видимо, сами придумали? Ну, к себе и претензии :)
Андрей Леонидович
1) отношения и кортежи не представляют никаких сущностей и экземпляров сущностей, и никаких связей между сущностями;
Подобные фразы в очередной раз выдают "lack of knowledge". Уясните, наконец, что кортежи представляют факты. Одним из возможных фактов может быть наличие в реальном мире некоторой сущности. Другим фактом (в другом отношении) может быть наличие в реальном мире "связи" между сущностями. Но и то, и другое - просто данные, семантика которых должна быть дополнительно объяснена. Модель данных занимается данными, но не их семантикой.
Андрей Леонидович
2) внешние ключи, соответствпенно, тоже не представляют никаких связей между сущностями;

Внешние ключи — это в первую очередь атрибуты, значения которых представляют определенные данные, которые в том числе можно интерпретировать как наличие логической «связи» данного факта с другим фактом, хранящимся в БД. Сама по себе декларативная ссылочная целостность просто позволяет СУБД контролировать непротиворечивость этих фактов. Конкретный «смысл» такой связи — опять же продукт интерпретации, с которой модель данных дела не имеет.
Андрей Леонидович
3) но домены и ключи - это "семантика" !
Называется, «сам-то понял, что сказал»? Домены — это множества, на которые определены отношения, ключи (кстати, какие?) — это подмножества атрибутов схемы отношения. И что? Что значит — это "семантика"? Какой-то бессмысленный набор слов, что для вас, впрочем, характерно.
Андрей Леонидович
Вот такая вот "теория", которой "оснащены" "Р"СУБД...
Только не в вашей «интерпретации». Ваши толкования больше напоминают старый анекдот:
— Миша, что все находят в этих Битлз? Шепелявят, слуха нет…
— А где ты их слушал?
— Да мне Рабинович вчера напел.

Андрей Леонидович
Не хотят люди ничего читать и понимать...
Как это верно :)
23 мар 05, 09:45    [1407461]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
ни нада... ни нада с ним разгаваривать... пажалуста... а то он никагда атсюда ни уйдет...
23 мар 05, 09:52    [1407481]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Первое и основное. Мне по большому счету все равно что сравнивать - сами СУБД или СУБД вместе с приложениями. Но главное, чтобы мы четко понимали именно то, что же мы все-таки сравниваем. Большим прогрессом я считаю тот факт, что мы наконец поняли разницу в этих двух подходах и можем ясно определиться с тем, какой подход нам подойдет больше.
23 мар 05, 10:00    [1407518]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
Alexey Rovdo
Мне по большому счету все равно что сравнивать - сами СУБД или СУБД вместе с приложениями.

Ну что ж, тогда я расчехляю аксес и мы начинаем считать, сколько мышиных кликов понадобится на создания отчета... И эту тему благополучно закрывают
(вместе с коллегой ЧАЛ)
23 мар 05, 10:08    [1407557]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
А по факту - тут, кажется, никому не интересно сравнивать приложения. Ни вместе с СУБД, ни вместо СУБД.
Так что (раз уж вам все равно) давайте сравнивать СУБД.
Где ваша СУБД, хранящая объекты?
23 мар 05, 10:12    [1407574]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
c127

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

Проведенный нами эксперимент показал как раз обратное: SQL код в РСУБД примерно в четыре раза короче джава кода в ООБД FastObjects. Хотите еще раз попробовать?


Вот именно здесь вы и занимаетесь выдергиванием из контекста.
Фраза "скорость и простота разработки (сложные схемы мэппинга при работе с ООСУБД строить не приходится, собственно обычно никакие схемы мэппинга строить не приходится)" была ответом на замечание Alex.Czech:

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


Т.е. речь шла о сравнении ООСУБД с комбинацией ORM+РСУБД, а вы мне опять тычете свой SQL-код в качестве контраргумента!

Яркий пример той ошибки, которую я раз за разом пытаюсь объяснить. Нужно четко конкретизировать ситуации, которые мы используем при сравнении. Иначе возникает полный бардак и непонимание. Также прошу следить за ходом дискуссии хотя на паре последних страниц - нельзя же в каждом сообщении повторять одно и то же.
23 мар 05, 10:15    [1407582]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Павел Воронцов

Alexey Rovdo
ООСУБД не живет без приложения.


О! Это Вы сами сказали! А любая SQL-СУБД, представьте себе, прекрасно живёт без приложения.


Да, это так. ООСУБД без приложения практически не имеет смысла. Это не значит, что данные из нее нельзя импортировать куда-нибудь (например, через ODBC), но как-то развивать (изменять) модель данных (да и сами данные) не получится. За это сторонники РСУБД всегда критиковали ООСУБД. Правда и объяснения сторонников РСУБД мне не кажутся слишком весомыми. Так, например, вовсе не очевидно, что возможность "жить без приложения" является жизненно необходимой для СУБД. Зачем нужна база без интерфейса доступа к ней?

Павел Воронцов

Или со многими приложениями. В моём текущем проекте базу за разные интерфейсы дёргают до десятка разных приложений, написанных на разных языках (в основном -Java & C). Причём некоторые из этихп риложений общаются с базой при помощи объектных интерфейсов (что-то типа Web-сервиса нагорожено). И всё этоживёт и отлично работает.


С ООСУБД также можно работать из множества разных приложений. Например FastObjects позволяет работать с одним хранилищем из приложений на C++, Java или языках платформы .NET. Есть к ООСУБД и классический SQL-ODBC интерфейс. Причем одно приложение может общаться со множеством хранилищ данных, по которым распределены объекты (поддерживаются и связи между объектами в разных хранилищах).
23 мар 05, 10:27    [1407625]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП
А по факту - тут, кажется, никому не интересно сравнивать приложения. Ни вместе с СУБД, ни вместо СУБД.
Так что (раз уж вам все равно) давайте сравнивать СУБД.
Где ваша СУБД, хранящая объекты?


В принципе при таком подходе у нас остается не так много механизмов, которые имеет смысл обсудить. Полагаю наиболее существенные отличия разных СУБД лежат в механизмах и принципах кластеризации, кэширования, поддержки прямой навигации и работе блокировок (с теорией мы вроде определились).
23 мар 05, 10:33    [1407650]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
To Alexwy Rovdo

Весь вопрос в том, как мы трактуем БД. Если это просто место, куда удобно "сериализовать" некие структуры и потом оттуда же очень ловко их доставать - это одно. Если же, как очень хорошо сказал mir СУБД призвана поддерживать в самосогласованном состоянии набор фактов, то это уже совсем другой коленкор. Тогда база важна "сама по себе".
23 мар 05, 10:43    [1407708]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
Alexey Rovdo
В принципе при таком подходе у нас остается не так много механизмов, которые имеет смысл обсудить. Полагаю наиболее существенные отличия разных СУБД лежат в механизмах и принципах кластеризации, кэширования, поддержки прямой навигации и работе блокировок (с теорией мы вроде определились).

В принципе обсудить можно.
Но, понимаете ли, лично мне - ну не очень интересно как что кешируется, как блокируется, как навигируется и как кластеризируется.
Мне объекты хочеца пощупать.
тут должен быть смайлик, изображающий рев в три ручья
23 мар 05, 11:26    [1407912]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЛП

Тут утверждалось, что в ООСУБД хранятся объекты.
А теперь вдруг оказывается, что в ООСУБД не хранятся объекты, и даже что ООСУБД для этого не подходят. Если от объекта откусить логику, то то, что останется - это вовсе даже не объект, а просто-напросто данные к нему.

Так что хранится в ООСУБД? Объекты? Или данные объектов? Ну так ведь и в РСУБД тоже хранятся данные объектов. Хде разница между ООСУБД и РСУБД?


Коллеги, практика этого форума показала, что терминологические споры тока уводлят от сравнения СУБД, но сами никак не разрешаются, и ничго не дают.
Почему бы нам до выяснения новых обстоятельств не придерживться общепринятого подхода: любая БД хранит в конечном счете данные (пусть в каком-то широком смысле), а не объекты (ООБД), не кортежи отношенийй (РБД). Иначе их следывало бы называть, не базами данных БД базами объектов БО и проч. А ОО и Р и проч происходит от модели данных, которая отвечает за структурирование данных, ограничения целостности и способы манипулирования данными.
И если уже все-таки грим, что она хранит объекты, то грить РБД хранит кортежи отношений. Иначе мы рискуем и дальше вязнуть в терминологических спорах, и выяснять хде мы находимся по отношению к терминологии в литре.
23 мар 05, 11:44    [1408011]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
ЛП

Но, понимаете ли, лично мне - ну не очень интересно как что кешируется, как блокируется, как навигируется и как кластеризируется.
Мне объекты хочеца пощупать.


Друх, ответь сам себе на вопрос - какие объекты в полном смысле слова могу быть в базе, если к нем надо делать доступ из С, C++, Smalltalk, Java, ODBC, JDBC?

Правильный ответ - не могут там быть объекты в полном смысле. Просто Java интерфейс доступа выдает тебе Java объекта, С доступ - структуры с указателями, и т.д. А консоль просто печатает тебе значения аттрибутов ну прям как sqlplus
23 мар 05, 11:47    [1408022]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП
А по факту - тут, кажется, никому не интересно сравнивать приложения. Ни вместе с СУБД, ни вместо СУБД.
Так что (раз уж вам все равно) давайте сравнивать СУБД.
Где ваша СУБД, хранящая объекты?


В принципе при таком подходе у нас остается не так много механизмов, которые имеет смысл обсудить. Полагаю наиболее существенные отличия разных СУБД лежат в механизмах и принципах кластеризации, кэширования, поддержки прямой навигации и работе блокировок (с теорией мы вроде определились).
23 мар 05, 12:12    [1408127]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
2 vadiminfo
Почему бы нам до выяснения новых обстоятельств не придерживться общепринятого подхода: любая БД хранит в конечном счете данные (пусть в каком-то широком смысле), а не объекты (ООБД), не кортежи отношенийй (РБД).

Хранилище данных - хранит данные (для чего-то).
Система управления хранилищем - системно управляет хранилищем данных
РБД хранит кортежи отношений. Выдает их пользователю (в каком-то виде)
ОБД хранит объекты. Выдает их пользователю (в каком-то виде).
Это - тавтология и общепринятый подход (я надеюсь).

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

На примере какого-нибудь прости господи экселя - я вполне могу себе представить как все это будет выглядеть (что-то - никак не будет выглядеть).

2 Dimonische
Друх, ответь сам себе на вопрос - какие объекты в полном смысле слова могу быть в базе, если к нем надо делать доступ из С, C++, Smalltalk, Java, ODBC, JDBC?

Друх, ответь сам себе на вопрос - какие объекты в полном смысле слова могут быть в экселе, если к объектам экселя имеется доступ из C, C++, Visual Basic, Java, и т.д.?
Правильный ответ - не могут там быть объекты в полном смысле.

Правильный ответ - самые обычные, интуитивно понятные объекты (в данном случае COM-объекты).
23 мар 05, 12:17    [1408154]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
2 Alexey Rovdo
Спасибо, я уже понял :)
23 мар 05, 12:18    [1408157]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Dimonische
Member

Откуда:
Сообщений: 137
ЛП


Правильный ответ - самые обычные, интуитивно понятные объекты (в данном случае COM-объекты).



Представил себе COM объекты на Солярисе - долго смеялся.
23 мар 05, 14:03    [1408651]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
Для тупых повторяю - в данном случае. Это раз.

Говорите долго смеялись? Вы будете плакать, но COM/DCOM на солярисе давным давно реализован. Это два.

Еще вопросы есть? Нет? Будете проходить мимо - проходите дальше.
23 мар 05, 14:52    [1408939]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП

Что такое объект - никто не сказал. Сказано было, что это "что-то общепринятое и интуитивно-понятное". Я хочу интуитивно понятные объекты из объектной базы.
Под объектной базой я готов понимать связку хранилище+апп-сервер, если уж по другому нельзя.


Почему трудно рассматривать ООСУБД в отрыве от приложения?
Именно потому, что манипулировать объектами без описания их классов проблематично. Строго говоря, объект в контексте хранилища данных ООСУБД представляет собой некий набор полей (атрибутов) с данными (ООСУБД поддерживает набор элементарных типов для таких полей). Что это за поля и как они структурированы задано в объявлениях классов (Java, C++, C# ... ). Эти метаданные (описания классов) также хранятся в хранилище данных ООСУБД, но в контексте хранилища - это просто еще одни наборы полей. Связать описания класов с самим объектами в полной мере мы можем только в приложении. И говорить об объектах в смысле Java мы можем только в контексте Java-приложения. А об объектах в смысле C++ - в контексте C++ приложения. В контексте только лишь хранилища данных ООСУБД - это все наборы полей, которые в разных приложениях и структурировать можно по разному. При определенных условиях мы даже можем использовать разные метаданные (описания классов) при обращении к одному и тому же хранилищу. И тогда в контексте разных приложений и сами объекты будут разными (на практике, впрочем, много чаще востребована обратная ситуация - одно хранилище метаданных для множества объектных хранилищ).

ЛП

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


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

ЛП

самые обычные, интуитивно понятные объекты (в данном случае COM-объекты).


С определенной натяжкой можно признать наличие некоторой аналогии между COM-объектами и Persistence-объектами (ну с очень большой натяжкой).

Но в данном случае мы не сравниваем СУБД. Мы рассматриваем технологию реализации (в т.ч. связывание с языками программирования) Persistence Framework - среды для работы с долгоживущими (сохраняемыми) объектами. Сам способ хранения таких объектов в правильно построенной Persistence Framework не должен оказывать влияния на код и порядок работы приложения. Можно только говорить об эффективности использования различных СУБД с такими средами.
23 мар 05, 15:00    [1408997]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
ЛП
Для тупых повторяю - в данном случае. Это раз.

Говорите долго смеялись? Вы будете плакать, но COM/DCOM на солярисе давным давно реализован. Это два.

Еще вопросы есть? Нет? Будете проходить мимо - проходите дальше.


Обалдеть. А на VMS тоже реализовано? А на Linux? А на OS/400? Ух ты, а я и не знал, сколько реализаций, и все работают. И что это их никто не использует, не понятно.

Если же говорить о выполнении методов на объектах, событий и пр., то есть объектные базы (см. соседний топик) типа Gemstone = Хранилище данных + Сервер приложений, который уже полноценно всякие методы зовет в Сервере приложений. Продвинуто. Но еще непонятней, чем просто объектные базы.

По поводу тупости, не буду спорить, как говориться, "не спорь с дураком, люди могут не заметить между вами разницы".
23 мар 05, 15:07    [1409047]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
2 Alexey Rovdo
Давайте для простоты пока COM-объекты и рассматривать (чтоб совсем в терминологии не запутаться)

Почему трудно рассматривать ООСУБД в отрыве от приложения?
Именно потому, что манипулировать объектами без описания их классов проблематично.

Надо приложению описание класса - он его получит. Хотя COM и через позднее связывание прекрасно живет. Любители Smalltalk'а этому факту наверное даже удивляться не будут.

Строго говоря, объект в контексте хранилища данных ООСУБД представляет собой некий набор полей (атрибутов) с данными (ООСУБД поддерживает набор элементарных типов для таких полей). Что это за поля и как они структурированы задано в объявлениях классов (Java, C++, C# ... ). Эти метаданные (описания классов) также хранятся в хранилище данных ООСУБД, но в контексте хранилища - это просто еще одни наборы полей.

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

И тогда в контексте разных приложений и сами объекты будут разными

Это все равно что сказать, что в контексте разных приложений кортежи, получаемые из РБД - будут разными. Не должны быть разными ни кортежи, ни объекты.
Для реляционных кортежей могут быть разные "обёртки" для доступа к ним (всякие там ado/dao/oledb/odbc/итд/итп). Для объектов могут быть разные "обёртки" для работы с ними (COM/DCOM/CORBA/итд/итп). Исполняемый код может отличаться (если это что-нибудь двухфазнокомпилируемое). Ну и что?

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

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

Но в данном случае мы не сравниваем СУБД. Мы рассматриваем технологию реализации (в т.ч. связывание с языками программирования) Persistence Framework - среды для работы с долгоживущими (сохраняемыми) объектами.

Повторяю пример с экселем. Эксель имеет некое хранилище, и хрен бы ним. Эксель как COM-сервер предоставляет конечному приложению множество объектов. Персистентных между прочим. Но эксель не является ООСУБД. Кстати, в экселе можно и кортежи отношений хранить, и стучаться к ним через одбц, но это не делает эксель РСУБД.
Так что я именно пытаюсь выяснить, что же именно поддерживают те СУБД, которые общепринято называть ООСУБД - из того, что должна поддерживать база данных чтоб не быть тупым экселем.
23 мар 05, 15:36    [1409269]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ЛП
Guest
Dimonische
Обалдеть. А на VMS тоже реализовано? А на Linux? А на OS/400? Ух ты, а я и не знал, сколько реализаций, и все работают. И что это их никто не использует, не понятно.

Учитесь пользоваться гуглом, может и найдете полный список платформ, на которые портирован COM.
23 мар 05, 15:38    [1409275]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
2 ЛП

Вы рассматриваете COM объекты, а выводы пытаетесь распространить на ООСУБД (или во всяком случае это так выглядит). Так что я в вашем рассуждении совсем запутался.

Постараюсь в общих чертах прояснить ситуацию в приложении к ООСУБД Versant.

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

Первое - конфликта на уровне методов быть не может - каждое приложение (клиент) отрабатывает код методов у себя.
Второе - для регулирования совместного доступа к начинке объектов (их данным) применяются классические механизмы блокировок, оптимистического и пессимистического доступа, такие же как и в РСУБД при совместном доступе к записям таблиц.

Блокировки гарантируют, что пока одно приложение работает с данными объекта эти данные не изменит другое приложение. Блокировки накладываются на объекты только в рамках транзакций. Любая работа с объектами вне рамок транзакций к блокировкам не приводит, но в этом случае нет гарантии того, что локальная копия данных объекта соответствует их текущему значению в хранилище данных. Существуют гибкие механизмы управления блокировками, позволяющие реализовать любые алгоритмы работы блокировок.
23 мар 05, 16:51    [1409750]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Фактически идентичный описанному выше алгоритм реализует и ORM-инструментарий Versant. Т.е. само хранилище объектов может быть и реляционным - ничего принципиально не меняется. Исключение, как я уже говорил выше, - механизм реакции на события, реализуемый именно в рамках ООСУБД.
23 мар 05, 16:55    [1409776]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mv
Member

Откуда:
Сообщений: 8876
Что вы там курите? Аж завидно...
23 мар 05, 23:53    [1410491]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЛП

Хранилище данных - хранит данные (для чего-то).
Система управления хранилищем - системно управляет хранилищем данных

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

ЛП

РБД хранит кортежи отношений. Выдает их пользователю (в каком-то виде)
ОБД хранит объекты. Выдает их пользователю (в каком-то виде).


Ну наверное можно сказать, что хранит данные в таким-то образом структурированные = хранит элементы этих структур. Лишбы не получилось так, что ООСУБД хранит объекты, а РСУБД - просто данные об объектах. Или что ООСУБД хранит объекты или данные об объектах - это не одно и тоже.
Тут еще, наверное, многозначность термина объект может путать. Объект реального мира - это одно, а объект - элемент структуры данных другое.
Тогда уж об объектах реального мира хранят данные в БД.
А вторые выдает пользователю.

ЛП

Что такое объект - никто не сказал. Сказано было, что это "что-то общепринятое и интуитивно-понятное". Я хочу интуитивно понятные объекты из объектной базы.

Ну объекты реального мира - что-то общепринятое и интуитивно-понятное.
Объекты как элементы структурироваения в моделях - тоже, наверное, полуинтуитивные, покрайней мере, пока в данной теме.


ЛП

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

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

Но хорошо, что появились, наконец-то представители известных в литре ООСУБД. Может дело пойдет.
24 мар 05, 01:05    [1410547]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 54 55 56 57 58 [59] 60 61 62 63 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить