Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
www.fun4me.narod.ru
Java, Linux, XML!

Java, Linux, XML!!

Java, Linux, XML!!!


А XML в FastObjects есть?


Есть
19 дек 04, 18:21    [1191891]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
Константин Лисянский
Кстати, похоже, у компании Versant дела не так уж и хорошо идут.

Акции очень уж неприятный тренд имеют.

Если посмотреть на тренд Nasdaq, то он не сильно отличается по форме. Хотя, очевидно, проблемы у Versant были. Сейчас, правда, у них глобальные реформы. Они прикупили Poet (благодаря чему в линейке продуктов появился Fastobjects), глобально реформируют структуру управления.
Константин Лисянский

Хотя, надо отдать должное, список клиентов, действительно впечатляет.
Не думаю, правда, что Россия является фокусным рынком. Судя по обороту, компания небольшая. Наверняка, представительства в России нету. Или есть?

Педставительств в России даже два (с 2004 года):
в С.Петербурге Ленвендо
в Москве Софткей
19 дек 04, 19:15    [1191912]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Lankaster
Если посмотреть на тренд Nasdaq, то он не сильно отличается по форме



Вы, наверное не смотрели. Иначе бы так не написали.
Давайте посмотрим. На графике Versant в сравнении с Microsoft и Nasdaq. Nasdaq (как и Microsoft) уверенно выше нуля, Versant уверенно ниже.

Педставительств в России даже два (с 2004 года):
в С.Петербурге Ленвендо
в Москве Софткей


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

Бизнес будет ломовой :))

Я не имел в виду патнёров. Я имел в виду представительство компании в виде офиса компании.


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


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 дек 04, 20:16    [1191935]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
Константин Лисянский
FastObjects uses B+ tree structures to build indexes

И всё?
Ну, тогда всё понятно. Btree-индексы хорошо подходят для приложений OLTP. В приложениях типа DSS неплохо ещё бы иметь другие типы индексов (например, bitmap-индексы, векторные индексы, MDC-индексы).
С уважением,
Константин Лисянский
http://lissianski.narod.ru

По поводу Btree-индексов - Я полностью согласен с ориентированностью на OLTP, это действительно так, но посмотрим на это с другой стороны: в правильно спроектированном приложении с ООМД, запросы в чистом виде практически не используются. Вся навигация идет по связям, а вот поиск по связям в объектных базах сделан существенно эффективнее чем просто B+ tree индексный поиск.
19 дек 04, 20:42    [1191948]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
Константин Лисянский
Педставительств в России даже два (с 2004 года):
в С.Петербурге Ленвендо
в Москве Софткей


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

С уважением,
Константин Лисянский
http://lissianski.narod.ru

Во-первых, 7 человек это только руководящие сотрудники компании. А во-вторых, важно не сколько человек, а какие люди. Мы плохих людей не держим! А ваш сарказм по поводу SoftKey на мой взгляд неуместен. Это одна из наиболее развитых компаний, занимающихся продажей ПО на Российском рынке.
19 дек 04, 20:48    [1191952]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
Константин Лисянский
Lankaster
Если посмотреть на тренд Nasdaq, то он не сильно отличается по форме

Вы, наверное не смотрели. Иначе бы так не написали.
Давайте посмотрим. На графике Versant в сравнении с Microsoft и Nasdaq. Nasdaq (как и Microsoft) уверенно выше нуля, Versant уверенно ниже.

Я говорил только о форме. Но тренд отрицательный, согласен.
19 дек 04, 20:56    [1191961]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
По поводу Btree-индексов - Я полностью согласен с ориентированностью на OLTP, это действительно так, но посмотрим на это с другой стороны: в правильно спроектированном приложении с ООМД, запросы в чистом виде практически не используются. Вся навигация идет по связям, а вот поиск по связям в объектных базах сделан существенно эффективнее чем просто B+ tree индексный поиск.


Правильно ли я понимаю, что СУБД Versant ориентирована на OLTP?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 дек 04, 21:27    [1191988]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Виталий Гаврилов
Во-первых, 7 человек это только руководящие сотрудники компании. А во-вторых, важно не сколько человек, а какие люди. Мы плохих людей не держим! А ваш сарказм по поводу SoftKey на мой взгляд неуместен. Это одна из наиболее развитых компаний, занимающихся продажей ПО на Российском рынке.


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


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 дек 04, 21:32    [1191991]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Виталий Гаврилов
По поводу Btree-индексов - Я полностью согласен с ориентированностью на OLTP, это действительно так, но посмотрим на это с другой стороны: в правильно спроектированном приложении с ООМД, запросы в чистом виде практически не используются. Вся навигация идет по связям, а вот поиск по связям в объектных базах сделан существенно эффективнее чем просто B+ tree индексный поиск.


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

Насчет того что существенно эффетивнее. Может ссылку какую приведёте откуда вы это взяли? Я например не думаю что очень существенно. Да, объект читается по связи, но он читается то только по одному, а вот если надо сразу диапазон какой выбрать - то не знаю что будет быстрее. Ну и к тому же если есть индекс то по нему можно сразу найти оптимальным образом нужный элемент, а по связам может придётся еще ходить и ходить.
19 дек 04, 23:07    [1192043]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
2Виталий Гаврилов:

Почитал сайт http://www.lenvendo.ru

Нашёл много орфографических ошибок. Из двух технических статей одна, похоже, находится на стадии творческих размышлений, вторая похожа на не очень удачный перевод материала, предназначенного для телекоммуникационного рынка США (у них там и дерегуляция и всё такое).

Некоторые заявления заставляют улыбнуться:

В то время как некоторые реляционные базы данных имеют пределы архитектуры в восемь-десять миллионов строк в таблице, Versant может поддержать до 2^48 объектов (2.81 тераобъектов) в каждой базе данных, и более чем 65000 баз данных в сети.


Какие интересно некоторые реляционные базы данных имеются в виду? 8-10 миллионов даже MS Access может потянуть.

Versant предоставляет и такие возможности как резервное копирование (которое поддерживает как полное, так и частичное копирование данных) и репликация для поддержки срочных резервных действий. Все эти возможности, вместе с такими особенностями, как динамическое изменение схемы, рекластеризация физической памяти и ее повторное использование – позволяет Versant поддерживать 24 x 7 телекоммуникационные приложения для решения критически важных, ответственных задач, чего не может ни одна другая база данных на современном рынке.


Довольно амбициозно, не правда ли? Думаю, найдётся масса желающих задать вопросы на этот счёт. Я то думал весь телеком живёт на Oracle в качестве систем OLTP, а оно вон как поворачивается :)

Рисунки в статье разглядеть невозможно. Некоторые рисунки отсутствуют вообще.

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

Виимо, вы сами не верили в то, что ваш сайт дальше первой страницы читать не будут.

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

А на вопросы по поводу параллелизма я так ответа и не получил.
И справедливо спрашивают по поводу не только навигации, но и эффективной работы с большими множествами однородных данных. При такой неразвитой системе индексирования не очень понятно, как это делается. Как насчёт возможности выполнения запросов (или что там ещё есть) к данным в условиях отсутствия описания связей между данными (т.н. запросы ad-hoc)? Что для этого нужно делать? Писать программу, писать SQL-запрос?
Я для себя пока понял так, что системы класса DSS на ООСУБД строить неэффективно из-за низкого быстродействия при характерном для DSS виде нагрузки. Про OLTP ничего не скажу, я этим не занимаюсь. Это пусть вас ораклоиды потрошат :)



С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 дек 04, 23:24    [1192054]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
vybegallo
Guest
Виталий Гаврилов
Константин Лисянский
FastObjects uses B+ tree structures to build indexes

И всё?
Ну, тогда всё понятно. Btree-индексы хорошо подходят для приложений OLTP. В приложениях типа DSS неплохо ещё бы иметь другие типы индексов (например, bitmap-индексы, векторные индексы, MDC-индексы).
С уважением,
Константин Лисянский
http://lissianski.narod.ru

По поводу Btree-индексов - Я полностью согласен с ориентированностью на OLTP, это действительно так, но посмотрим на это с другой стороны: в правильно спроектированном приложении с ООМД, запросы в чистом виде практически не используются. Вся навигация идет по связям, а вот поиск по связям в объектных базах сделан существенно эффективнее чем просто B+ tree индексный поиск.


Мне одному кажется, что это те же сетевые БД, вид сбоку ?
И достоинства (быстродействие при доступе "по указателям") и недостатки (медленный доступ "по значению", сложности модицикации структур при изменении задачи) давно известны, сто раз обсосаны, жизнь всех расставила по местам - где Оракл и где Б-Трив ?
20 дек 04, 17:41    [1194534]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

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

Вообще пора еще раз напомнить об одном важном заблуждении, у которого весьма глубокие исторические корни (см. следующее сообщение).
20 дек 04, 17:49    [1194573]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Всем известно, что сегодня подавляющее большинство систем хранения данных строится на базе т.н. реляционных СУБД. За 35 лет существования этой технологии уже успело вырасти целое поколение архитекторов и разработчиков, которые настолько привыкли и притерлись к особенностям существующих реляционных решений, что просто не допускают и мысли об использовании чего-то иного. Однако, если углубиться в прошлое, то можно увидеть, что используемая сегодня реляционная технология была вовсе не первым и не единственным из предлагавшихся подходов. В свое время вокруг этой темы кипели нешуточные страсти и ломалось немало копий. Чего стоят только названия некоторых ключевых событий этих сражений: «Великий спор», «Первый манифест», «Второй манифест» и т.д.
Когда в 1969 году вышла первая статья Эдгара Кодда, посвященная реляционной модели, в мире баз данных бал правили CODASYL, со своей сетевой моделью хранения данных, и иерархическая СУБД IMS от компании IBM. Понадобились годы напряженного труда, тщательных научных изысканий и жарких дискуссий, наиболее примечательные из которых происходили на конференциях ACM SIGMOD в ноябре 71 в Сан Диего и в мае 74 в Мичигане. И только к концу 70-х появились первые работоспособные образцы реляционных СУБД. Популяризация и коммерциализация разработок заняли еще целое десятилетие, а их доводка и совершенствование продолжаются и поныне. Но наука никогда не стояла на месте и вслед за реляционной теорией появилась масса других, претендующих на звание лидера и на ее место в мире СУБД. И среди таких теорий особое место занимает объектно-ориентированный подход.
Здесь стоит также отметить, что историю объектно-ориентированного подхода к хранению данных нельзя рассматривать вне контекста развития объектно-ориентированного программирования в целом. Именно разработка и реальное применение на практике первых объектных языков программирования, таких, например, как Object Lisp и особенно Smalltalk, привели исследователей к пониманию того факта, что реляционные СУБД никак не вяжутся с объектной парадигмой, предлагаемой этими языками. Первые идеи о необходимости реализации именно объектного хранения данных высказывались в научном сообществе уже в конце 70-х годов, однако в практическую плоскость они вылились только к началу 80-х, когда стартовали первые исследовательские проекты в этом направлении.
Самой первой коммерческой объектно-ориентированной СУБД принято считать разработку компании GemStone Systems, осуществленную в 83-84 годах и выведенную на рынок в 87. Вскоре за ней последовали и другие. Многие из них родились в стенах известнейших университетов и стали своего рода фундаментом для систем следующих поколений.
Разработка и выход первых объектных СУБД сопровождались активными дискуссиями в научном сообществе. И если в начале 80-х ученый мир в основном знакомился с этой технологией, впитывая и переваривая ее основные идеи, то ко второй половине этого десятилетия в нем воцарилась настоящая эйфория. Казалось, что еще чуть-чуть и волна новых объектно-ориентированных решений сметет с рынка только вошедшие в силу реляционные СУБД так же, как они когда-то смели решения CODASYL. В 1988 году прошел организованный университетом Беркли симпозиум разработчиков баз данных, отчет о котором, ставший широко известным под названием Laguna Beach Report, уже содержал все основные идеи объектно-ориентированных СУБД и объявлял эту линию как одну из самых перспективных в отрасли. А в 1989 году на конференции в Киото был принят т.н. «Первый манифест объектно-ориентированных СУБД», безоговорочно отдававший приоритет дальнейшего развития в руки разработчиков объектных СУБД. Тема развития объектного подхода к управлению данными оказалась настолько востребованной, что в составе консорциума Object Management Group в 1991 году была образована специальная группа ODMG для стандартизации отдельных решений по хранению и доступу к объектным данным. Забавно, что в последующем идеи, выработанные этой групой, оказали весьма значительное влияние на становление популярнейшего сегодня языка UML и некоторых других стандартов.
Но к началу 90-х вспыхнувшая в научных кругах эйфория стала постепенно затихать. Оказалось, что для объектных СУБД очень трудно построить такое же простое и полное теоретическое обоснование, которое нашел Кодд для реляционной модели. К тому же, многие практические реализации объектных СУБД были слишком узко специализированы и ориентировались на постепенно вытесняемый язык Smalltalk, вместо активно развивающегося C++, а компании, вложившие средства в разработку систем на базе реляционных СУБД, просто не желали переучивать людей и переходить на новые технологии. Начались попытки каким-то образом связать объектный подход с реляционным, обеспечив пользователям возможность плавного перехода от одного к другому.
Начало и середина 90-х — достаточно сложный для объектных СУБД период. Будучи противопоставлены реляционным решениям, они подвергались множеству нападок и откровенному остракизму как со стороны основных идеологов индустрии, так и со стороны архитекторов и разработчиков информационных систем. Достаточно вспомнить т.н. «Манифест 3-го поколения СУБД», озвученный на конференции ACM SIGMOD в 90 году Майклом Строунбейкером — отцом-основателем системы Illustra, которая дала начало целой ветви так называемых объектно-реляционных СУБД. Но особенно можно отметить «3-й манифест объектно-ориентированных СУБД» Кристофера Дейта и Хью Дарвина, впервые озвученный в 95 году и подробно изложенный в их книге, вышедшей в 98 году. Теория, активно продвигавшаяся Крисом Дейтом в те годы, практически говорила о том, что право на существование имеет только чистый реляционный подход, а объектно-ориентированные и любые другие системы вполне могут быть представлены в рамках реляционной модели. Забавно, кстати, что и популярнейшие в то время СУБД от Oracle и IBM Дейт считал совсем нереляционными и предлагал отказаться от многих привычных уже вещей, вроде языка SQL.
Примечательно будет отметить, что только что упомянутая мною книга Кристофера Дейта «3-й манифест объектно-ориентированных СУБД», безусловно очень интересная, но вышедшая на западе в 1998 году, была издана на русском буквально пару месяцев тому назад и во многом воспринимается и рекламируется у нас как последнее слово в развитии баз данных.
Ровно тоже можно сказать и про подавляющее большинство другой литературы, которая была написана в годы противостояния (90-е). Везде констатируется, что реляционные СУБД "победили", а объектные СУБД влачат жалкое существование.
Но на самом деле случилось то чего никто не ждал — фактически сегодня произошло естественное примирение двух казалось бы антагонистических концепций: объектной и реляционной. Как же и на основе чего это произошло? Оказалось, что это две стороны одной медали и сам метод хранения данных не имеет такого уж большого значения. Любые данные, будь то объектные или реляционные, можно преобразовывать из одной формы в другую по определенному набору правил и хранить как в объектных, так и в реляционных базах данных. Гораздо большее влияние на выбор архитекторов и разработчиков стали оказывать такие факторы, как поддержка мультипотоковости и мультипроцессорности, механизмы резервирования и защиты, средства бэкапирования и восстановления после сбоев, развитый инструментарий разработчика и средства обработки запросов. Т.е. сама внутренняя архитектура используемой СУБД вообще перестала быть определяющей (достаточно взглянуть на приводимую здесь аргументацию сторонников Oracle, которые больше упоминают проверенность и конкретную функциональность этой системы, а не методику хранения данных). Разумеется я не претендую на всеохватность данного утверждения.

С уважением,
Алексей Ровдо.
20 дек 04, 18:07    [1194640]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Везде констатируется, что реляционные СУБД "победили", а объектные СУБД влачат жалкое существование.


Свидетельством чего является хотя бы то, что о них тут никто ничего не знает.
Равно как и доля рынка, количество специалистов и другие факторы.
Другими словами, это нишевые СУБД. И пока им там и место. Причём, я не оспариваю того, что что-то они определённо делают лучше реляционных СУБД, но в целом они проигрывают. ИМХО.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
20 дек 04, 18:36    [1194749]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Sp1Der
Member

Откуда: Санкт-Петербург
Сообщений: 39
Константин Лисянский
Везде констатируется, что реляционные СУБД "победили", а объектные СУБД влачат жалкое существование.


Свидетельством чего является хотя бы то, что о них тут никто ничего не знает.


а может это является свидетельством лишь вашего незнания, и ничего более?
20 дек 04, 18:39    [1194766]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Константин Лисянский
[quot ]Причём, я не оспариваю того, что что-то они определённо делают лучше реляционных СУБД, но в целом они проигрывают. ИМХО.

Не может быть системы на базе ООСУБД, которая в частности великолепно решает поставленную задачу, но "в целом" хуже, чем аналогичная система на базе РСУБД. Потому что конкретные проекты делаются для решения конкретных проблем (а не решения всех проблем "в целом").
Разумеется большинство сегодняшних бизнес-задач эффективнее решается с помощью РСУБД, но есть задачи в решении которых ООСУБД значительно!!! эффективнее РСУБД. Именно данное высказывание по сути и задало тему данного топика. Можно согласиться с тем, что задачи для ООСУБД имеют четко выраженный нишевый характер, но в своей нише ООСУБД вне конкуренции и агитация за использование Oracle или MS SQL во всех ситуациях является ошибкой и свидетельствует о непрофессионализме тех, кто за это ратует.
Впрочем, есть темы и задачи, для которых выбор не столь однозначен, и возможно наблюдаемая здесь дискуссия поможет определиться тем, кто действительно хочет объективно подойти к выбору платформы, на которую затем прийдется опираться многие годы.
20 дек 04, 19:02    [1194829]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Я честно пытался получить ответы на вопросы, но не получил.
Получил только маркетинговые заявления.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
20 дек 04, 19:08    [1194842]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Вот здесь кроется основное заблуждение:
Alexey Rovdo
Но на самом деле случилось то чего никто не ждал — фактически сегодня произошло естественное примирение двух казалось бы антагонистических концепций: объектной и реляционной. Как же и на основе чего это произошло? Оказалось, что это две стороны одной медали и сам метод хранения данных не имеет такого уж большого значения. Любые данные, будь то объектные или реляционные, можно преобразовывать из одной формы в другую по определенному набору правил и хранить как в объектных, так и в реляционных базах данных.


Хоть РСУБД сейчас и навешиваются объектными и процедурными возможностями, концепции остаются каждая сама по себе.
В объектной концепции каждый объект - это свой мир со своим поведением. В реляционной всё изначально строго упорядочено. Это позволяет не заниматься программированием процесса последовательных операций, а манипулировать именно данными. Причем сервер, сам зная структуру данных и статистику их распределения, выбирает как ему с данными работать. Любой элемент процедурности (например UDF) уже вносит тормоза - сервер не знает что вернёт функция пока не выполнит её.
Да, конечно в каких-то случаях удобно использовать UDF. Но когда большие объёмы данных надо обрабатывать за небольшое время - приходится как-то обходится без них. Наверное кое-где можно было бы использовать некоторые элементы ООП. Но только там где скорость не важна.
20 дек 04, 19:14    [1194850]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
Константин Лисянский

Правильно ли я понимаю, что СУБД Versant ориентирована на OLTP?


С уважением,
Константин Лисянский
http://lissianski.narod.ru

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

Легко.
Пример.
Class MapElement{
Point position;
MapElement parent;
List childs;
List objects;
}
Class MapObject{
// некие поля объекта на карте такие как координаты, размер и т.д.
}
Class Tree extends MapObject{
// класс дерево :-)
}
Теперь мы хотим прочитать вложенные элементы карты, это доступ по ссылке.
Хотим прочитать все объекты на карте (нам их нарисовать надо), это опять доступ по ссылке.
Хотим найти объект по имени - это запрос на OQL который возвращает список объектов. Для такого запроса вполне достаточно btree индекса, хотя hash индекс был бы вероятно эффективней. И если для Вашей конкретной задачи необходимо именно такое индексирование (по строке или по строке и набору других параметров) то никто не мешает вам построить свой класс или набор классов и реализовать в нем тот поиск, который будет для Вас более эффективен. Инструментария БД Вам хватит а объектная субд упростит Вашу работу по созданию этого класса. И не говорите мне что РСУБД сделает это лучше т.к. ВСЕ универсальное работает медленнее специального. Надеюсь с этим утверждением никто спорить не будет?
Я ответил на вопрос?
SergSuper
Насчет того что существенно эффетивнее. Может ссылку какую приведёте откуда вы это взяли? Я например не думаю что очень существенно. Да, объект читается по связи, но он читается то только по одному, а вот если надо сразу диапазон какой выбрать - то не знаю что будет быстрее. Ну и к тому же если есть индекс то по нему можно сразу найти оптимальным образом нужный элемент, а по связам может придётся еще ходить и ходить.

Я приведу пример, ок?
Class A{
int F1;
String S1;
}
Class B extends A{
Date D1;
}
Class C extends A{
List L1; //элементов A
}

Структура для РСУБД
Table A
integer ID PK // primary key
integer f1;
Varchar(8000) s1

Table B
integer ID PK, FK // primary key + FK
DateTime D1

Table C
integer ID; PK, FK // primary key + FK

Table C_A
integer parent; // FK на таблицу C
integer child; // FK на таблицу A + PK по полям parent+child

Запрос для чтения B
Select ... from B inner join A
Запрос для чтения C
Select ... from C inner join A inner join C_A inner join A

Для чтения A и всех потомков
Select ... from A left join B left join C left join C_A left join A
т.е. запрос всязывает до четырех таблицб приэтом мы вынуждены или слать 2-а запроса на чтение C или потом внимательно разбирать результат одного запроса.

В объектной СУБД любая из задач - один запрос безо всяких если. И запрос гораздо более простой. И читается объект целиком а не частями по разным таблицам собирается.
А по поводу чтения по одному Вы ошибаетесь, посмотрите в стандарте ODMG.
Надеюсь ответил понятно.
20 дек 04, 19:24    [1194861]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
>> Хотим найти объект по имени - это запрос на OQL который возвращает список объектов. Для такого запроса вполне достаточно btree индекса, хотя hash индекс был бы вероятно эффективней.

Вообще по поводу индексов.
Versant Developer Suite поддерживает и hash, и btree индексы.
FastObjects работает на базе btree индексов, но этот продукт и позиционируется для не слишком больших баз данных и более мягких режимов работы. Тем не менее и в нем есть возможность использования внешних Index-engines, например для реализации полнотекстового поиска (есть заказчики, использующие эту возможность).
20 дек 04, 19:49    [1194917]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Виталий Гаврилов
Хотим прочитать все объекты на карте (нам их нарисовать надо), это опять доступ по ссылке.
Хотим найти объект по имени - это запрос на OQL который возвращает список объектов. Для такого запроса вполне достаточно btree индекса, хотя hash индекс был бы вероятно эффективней. И если для Вашей конкретной задачи необходимо именно такое индексирование (по строке или по строке и набору других параметров) то никто не мешает вам построить свой класс или набор классов и реализовать в нем тот поиск, который будет для Вас более эффективен. Инструментария БД Вам хватит а объектная субд упростит Вашу работу по созданию этого класса.

Итак список объектов, потом чтение полей объектов против получения одним запросом всего сразу. На мой взгяд последнее быстрее - сервер сам балансирует индексы, выбирает оптимальный путь выборок. Например надо выбрать объекты в определённом квадрате определённого типа. В зависимости от размера квадрата и типа оптимальный порядок в какой последовательности искать (сначала по координатам, а потом по типу или наоборот) может быть разный. Оптимизатор РСУБД это учтёт (во всяком случае попытается), вы же должны жестко задавать алгоритм поиска (либо сами расписывать варианты).
К тому же запросы я могу легко менять, а вам если что надо добавлять новые ссылки в объект.

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

Ну и трудно на последок удержаться:
Виталий Гаврилов
В объектной СУБД любая из задач - один запрос безо всяких если. И запрос гораздо более простой.

Однако ж запрос на SQL Вы привели, а для объектной СУБД - нет :)

Виталий Гаврилов
И читается объект целиком а не частями по разным таблицам собирается

А два объекта? :)
20 дек 04, 20:01    [1194936]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
SergSuper
Однако ж запрос на SQL Вы привели, а для объектной СУБД - нет :)

Запрос я привел для реляционной СУБД для того чтоб показать сложность задачи. Для объектной это выглядит так:
Select * from A
Вернет все объекты класса А и потомки классов В и С
Причем параметрами запроса можно выбрать только Объекты класса А
Select * from B
Вернет все объекты класса В
Select * from C вернет все объекты класса С

Выглядит проще, не так-ли?

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

Видимо вы поняли меня неправильно, объект читается ЦЕЛИКОМ
SergSuper
Например надо выбрать объекты в определённом квадрате определённого типа. В зависимости от размера квадрата и типа оптимальный порядок в какой последовательности искать (сначала по координатам, а потом по типу или наоборот) может быть разный. Оптимизатор РСУБД это учтёт (во всяком случае попытается), вы же должны жестко задавать алгоритм поиска (либо сами расписывать варианты).

А зачем искать если вся информация Вам доступна по ссылкам?
Необходимость этого отпадает сама собой.
Просто технология проектирования системы под ОБД несколько отличается от проектирования под РБД.
SergSuper
К тому же запросы я могу легко менять, а вам если что надо добавлять новые ссылки в объект.

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

это был только пример, а принимать мой аргумент или нет решать Вам.
SergSuper
Ну и трудно на последок удержаться:
А два объекта? :)

И два объекта тоже читаются целиком. И даже 100 объектов тоже целиком. Но подгружаться они могут разными способами:
1. все 100 сразу в память
2. по мере обращения каждуй следующий.
3. в паралельном потоке в фоновом режиме.
20 дек 04, 20:21    [1194965]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
SergSuper
Итак список объектов, потом чтение полей объектов против получения одним запросом всего сразу. На мой взгяд последнее быстрее - сервер сам балансирует индексы, выбирает оптимальный путь выборок.


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

SergSuper

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


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

SergSuper
А два объекта? :)

Групповые операции и шаблоны доступа позволяют очень гибко осуществлять выборку данных из базы. Ничего лишнего с сервера на клиента тащить не прийдется.
20 дек 04, 20:32    [1194978]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
Виталий Гаврилов
И не говорите мне что РСУБД сделает это лучше т.к. ВСЕ универсальное работает медленнее специального. Надеюсь с этим утверждением никто спорить не будет?


А почему бы и не поспорить?
В ОРСУБД иерархические структуры тоже можно достаточно просто хранить и обрабатывать. Вот пример.

Что касается карт, то при работе с ними часто нужно найти объект находящийся на расстоянии не более заданного. Здесь ООСУБД предлагает последовательный перебор, а в ОРСУБД можно воспользоваться R-tree индексом.
20 дек 04, 21:06    [1195015]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Константин Лисянский

Правильно ли я понимаю, что СУБД Versant ориентирована на OLTP?


Виталий Гаврилов
Нет.


Ну, тогда, спозиционируйте её, пожалуйста. Или она для любых задач подходит? Как насчёт хранилищ данных (data warehousing)?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
20 дек 04, 21:59    [1195063]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить