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

Откуда:
Сообщений: 37
Alexey Rovdo
но сама схема мало чем отличается от работы типичных ORM-средств


В корне неправильное утверждение. Начнем, хотябы с того, что данные в Cache' храниятся ну совсем не в реляционных таблицах, а в многомерные массивы (глобалах) организованных по принципу B*-tree. Так что не о каком ОRM здесь речи не идет.

Versant, наверное тоже использует некую комбинацию хеш-таблиц и Б деревьев или их вариаций в качестве внутренней структуры базы? Но ведь это совсем не повод утверждать что "Работать это быстро не может по определению, потомучто представляет собой всего лишь разновидность меппинга объектов на низлежащие структуры".
15 мар 05, 15:53    [1387357]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Alexey Rovdo

Так ведь нет у ООСУБД такой же полной и внятной теории, которая есть у реляционных систем!

Что это значит? Считаете ли Вы это недостатком. Насколько серьезным? Преодолимым в будущем?



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

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

Если говорить о будущем, то я бы сказал, что в ближайшие 5-10 лет ситуация вряд ли может сильно измениться. Основные идеологи ООСУБД пока не договрились между собой о множестве ключевых положений этой концепции. Скорее всего все ждут, что именно рынок расставит все по своим местам и выживут именно те решения, которые окажутся наиболее удачными. Научный интерес к ООСУБД, значительно угасший в середине и конце 90-х, сейчас испытывает некоторый подъем. Возможно это и приведет к каким-то заметным результатам в будущем.

vadiminfo

Вы раньше вели разговор о преимуществах производиельности ООСУБД.
Счтиаете ли Вы что ООСУБД быстрей на любых задачах и в тех где РСУБД "хорошо себя чувствует"? Тоже считаете непреодолимым недостатком? Зависимым от модели?


vadiminfo

Например, Ваши доводы про указатели или ссыслки в оперативной памяти, относятся не только к ООСУБД, но к иерархическим СУБД. Когда-то они были много быстрей. Но положение дел изменилось, а основные проблемы не с оперативной памятью а с чтением с диска. В РСУБД одно из направлений работ связано с дальнейшим повышением производительности. Если же Вы приводите пример, где РСУБД вообще "плохо себя чувствует", то там должно быть кое-что и похуже проблем производительности.


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

Всегда были о продолжают развиваться другие направления автоматизации человеческой деятельности. Более того, сложность типовых бизнес-задач постоянно растет, что неизбежно сказывается и на структуре и способах организации данных в соответствующих информационных системах. Уже давно публично признана и проблема "несоответствия импедансов" (impedance mismatch), проявляющаяся на стыке реляционной БД и ОО-приложения. Развитие таких ОО-языков как Java, C++, C# только еще больше высвечивает этот аспект, вынуждая разработчиков искать хоть какие-то альтернативы реляционным хранилищам. И именно ООСУБД сегодня такие альтернативы предлагают.

Т.е. в целом я совершенно согласен с тем, что ООСУБД распространены на порядок меньше, чем РСУБД. Но, например, самая большая в мире база данных SLA построена на базе ООСУБД. В военной сфере ООСУБД всегда применялись весьма активно. В бионформатике и генетическом анализе им практически нет альтернативы сегодня. Телекоммуникации — достаточно широкая и разнообразная сфера, но в ней также есть сегменты, в которых ООСУБД всегда были сильны и очень популярны. Ну а потребительские свойства по мере развития продуктов только улучшаются, и если лет 7 назад это действительно было проблемой ООСУБД, то сегодня я не вижу сложностей именно с этой точки зрения. Основная проблема в России — неинформированность.

Кстати пример с иерархическими СУБД хорошо иллюстрирует один важный факт. Если есть сферы деятельности, для которых некая модель оказывается наиболее удачной, то переход на любую другую (более универсальную, более навороченную, продвинутую и т.п.) технологию в таких сферах является вредным и никому, кроме производителей самих баз данных, не нужен. Достаточно зайти на сайт IBM и убедиться в том, что иерархическая СУБД IMS, о которой мы здесь обычно говорим как о чем-то оставшемся далеко-далеко в прошлом, живет и здравствует. Т.е. есть задачи, в которых именно иерархические СУБД оказались востребованы, и пока эти задачи существуют скорее всего будут существовать и иерархические базы данных (просто потому, что они подходят идеально именно под эти задачи). Все это в равной мере можно распространить и на реляционные, и на объектные системы.
15 мар 05, 16:24    [1387594]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
aou
Alexey Rovdo
но сама схема мало чем отличается от работы типичных ORM-средств


В корне неправильное утверждение. Начнем, хотябы с того, что данные в Cache' храниятся ну совсем не в реляционных таблицах, а в многомерные массивы (глобалах) организованных по принципу B*-tree. Так что не о каком ОRM здесь речи не идет.

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


Разумеется, не в реляционных. Поэтому для Cache ORM надо переименовать в O[Глобали]M . Впрочем давайте разберемся детальнее. Скажем у меня есть один объект-родитель, который в качестве атрибута содержит коллекцию ссылок на некие дочерние объекты. Как в Cache будет храниться такая конструкция? Что представляют собой ссылки и коллекции ?
Обычный ORM предложит в таком случае создать две таблицы со связкой PK-FK и соответствующий индекс по FK. Versant будет хранить коллекцию ссылок именно как объект-коллекцию вместе с родительским объектом (в составе его атрибутов), а ссылки будут представлять собой физические адреса и уникальные OID дочерних объектов в файле БД.
15 мар 05, 16:44    [1387694]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 aou

>>В корне неправильное утверждение. Начнем, хотябы с того, что данные в Cache' храниятся ну совсем не в реляционных таблицах, а в многомерные массивы (глобалах) организованных по принципу B*-tree. Так что не о каком ОRM здесь речи не идет.


Может для вас это окажется новостью, но Oracle например тоже может хранить данные не в таблицах (строго говоря он в таблицах их и не хранит), а в тех же B*tree. Подозреваю, что DB\2, MSSQL etc тоже так умеют.

Только это далеко не всегда выгодно, собст-но потому и существуют другие способы хранения.

То что в М-системах 70 было основной фичей, сейчас рядовая возможность современных СУБД.
15 мар 05, 17:02    [1387789]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
Alexey Rovdo
Скажем у меня есть один объект-родитель, который в качестве атрибута содержит коллекцию ссылок на некие дочерние объекты. Как в Cache будет храниться такая конструкция? Что представляют собой ссылки и коллекции ?


Отношение Parent-Child будет физически хранится в подузлах глобали (в томже месте, без всяких дополнительных таблиц и FK). Если повезет - даже окажутся физически в томже блоке/странице данных. Тоже самое для встроенных объектов и коллекций.
15 мар 05, 18:31    [1388182]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
2 Andreww:

Совсем не новость. За редким исключением типа TimesTen все современные СУБД используют ту или иную комбинацию B*Tree и Хеш таблиц.

Вопрос собственно в том насколько эффективно и гибко та или иная СУБД позваляет упровлятся с этими структурами.
15 мар 05, 18:42    [1388212]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Alexey Rovdo

У меня к Вам пара вопросов, касающейся вашего утверждения о том, что ООDB (тот же VERSANT) позволяет хранить сложные структуры. Мне интересно, насколько сложные. Я, конечно, могу ошибатья, посткольку с С++ работал давно, а Java смотрел только в теории.

Вопрос 1
Есть классы А и B, причем класс В содержит атрибут, представляющий собой объект класса А.

class A
{...}

class B
{...
А atr;
...}


В С++ (насколько мне не изменила память, а если изменила - убейте меня на месте, поскольку я зря Вам полощу здесь мозги....(это я Бабеля начитался )) эта ситуация означает, что объект аtr реально является частью объекта класса B. То есть операция new B выделит память и для atr (единственное что может для atr потребоваться - конструктор). В Java же atr будет рассматриваться как ссылка на объект класса А, что обязательно требует для atr вызова операции new. То есть в C++ мы получаем действительно сложную конструкцию, в Java мы получаем эмуляцию этой сложной конструкции через ссылку (в С++ для этого мы должны были бы написать atr& A или даже atr* A ). То, что Versant сожрет вариант эмуляции через ссылку (трактовка Java) - не сомневаюсь. А вариант действительно сложной конструкции (трактовка C++) он так же легко переварит?

Вопрос 2

class B
{...
int[] atr;
...}


Массивы - они в Java только диначические. То есть каждому массиву нужен свой оператор new int[100], исходя из чего я также утверждаю, что здесь нет сложной структуры, а есть ее эмуляция через ссылку. В С++ легко сделаем

class B
{...
int[100] atr;
...}


и это действительно будет сложная структура.
Versant оба варианта переварит?
15 мар 05, 18:52    [1388239]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

...
Есть классы А и B, причем класс В содержит атрибут, представляющий собой объект класса А.

...
и это действительно будет сложная структура.
Versant оба варианта переварит?


В Versant можно работать со всеми вариантами, которые вы представили. И Versant FastObjects, и Versant Developer Suite могут работать с объектами и объектными сетями неограниченной сложности (в рамках доступной памяти). Т.е. сложный объект может и сам содержать десятки тысяч встроенных объектов и содержать ссылки (указатели) на десятки тысяч других объектов. Массивы, коллекции, карты и пр. также поддерживаются (т.е. могут быть атрибутами объектов).

В FastObjects можно работать с Java, C++ и С# (и др. .NET-языки).
В Versant Developer Suite - c С++, а также и с Java через Versant Open Access JDO.
15 мар 05, 19:11    [1388278]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 aou

>>Совсем не новость. За редким исключением типа TimesTen все современные СУБД используют ту или иную комбинацию B*Tree и Хеш таблиц.

Вроде речь шла про хранение ? Изначально было :
" ... данные в Cache' храниятся ну совсем не в реляционных таблицах, а в многомерные массивы (глобалах) организованных по принципу B*-tree ..."

Оказалось, что сейчас везде так хранится.

Теперь стало :

>> Вопрос собственно в том насколько эффективно и гибко та или иная СУБД позваляет упровлятся с этими структурами.

Что ж, давайте посмотрим на оптимизатор Oracle или MSSQL (что вам ближе), именно так эти СУБД работают со своими структурами.

Что тут можно сказать про эффективность Cache ? Как у неё происходит оптимизация работы с этими структурами, и происходит ли ?

>>Отношение Parent-Child будет физически хранится в подузлах глобали (в томже месте, без всяких дополнительных таблиц и FK).

А если у меня нету для моих данных отношения Parent-Child ?
А если у меня для моих данных можно построить много таких отношений и все они важны для отчётности ?

>>Если повезет - даже окажутся физически в томже блоке/странице данных. Тоже самое для встроенных объектов и коллекций.

Что значит "то же самое" ?

Вопросов пока много, ответов пока нет :(

Яркие и эксцентричные "выступления" коллеги ЧАЛ-а не в счёт.
15 мар 05, 19:15    [1388287]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
aou
Alexey Rovdo
Скажем у меня есть один объект-родитель, который в качестве атрибута содержит коллекцию ссылок на некие дочерние объекты. Как в Cache будет храниться такая конструкция? Что представляют собой ссылки и коллекции ?


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


Т.е. само отношение Parent-Child рассматривается как отдельный объект? А, скажем, коллекция - это некое множество объектов типа отношение ?
А что значит "если повезет" ? И что вы понимаете под встроенными объектами и коллекциями ?

В терминологии Versant встроенный объект (объект вторичного класса) - это объект, который фактически является частью (атрибутом) некого родительского объекта-контейнера и не имеет своего уникального объектного идентификатора. Таким образом ссылки на встроенные объекты невозможны, а доступ к ним осуществляется только через родительский объект-контейнер. Хранение данных встроенных объектов осуществляется единым блоком вместе со всеми данными объекта-контейнера.
15 мар 05, 19:21    [1388305]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Guest_New
Guest
Alexey Rovdo
В Versant Developer Suite - c С++, а также и с Java через Versant Open Access JDO.


Хочу уточнить... У VDS (Versant Developer Suite) есть Java Versanst Interface.
Он не завязан на Versant Open Access JDO. Хотя и через JDO работать тоже можно.
15 мар 05, 19:22    [1388308]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
JVI можно считать мертвой веткой. Он появился как свой вариант Java-интерфейса, когда стандарт JDO только формировался. Versant не планирует развивать это направление, поскольку с утверждением спецификации JDO полностью переориентировалась на поддержку этой технологии. Полагаю, что в следующей версии VDS 7.0, планирующейся к выходу летом, JVI даже может уже и не быть (а может для сохранения совместимости о оставят). Так что писать приложения с использованием JVI я бы никому не рекомендовал.
15 мар 05, 19:30    [1388327]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
Т.е. само отношение Parent-Child рассматривается как отдельный объект?

Нет. Есть объект-родитель, а есть связанные с ним объекты - дети (не путать с наследованием).

А, скажем, коллекция - это некое множество объектов типа отношение ?

Нет. Коллекция это коллекция (см ниже).

А что значит "если повезет" ?

На самом низком уровне данные хранятся в блоках по 8к. Объект - "ребенок" хранится вместе с объектом "родителем", но если объем данных так или иначе перейвалит отметку в 8к - есть шанс что "ребенок" попадет не в тотже, а в соседний блок. (Почуствуйте разницу с двумя принципиально разными таблицами в РСУБД)

И что вы понимаете под встроенными объектами и коллекциями ?

Под встроенными объектами, полагаю, тоже что и вы под "объектом вторичного класса"- они физически хранятся как составная часть объекта, в который он встроен и собственного OID не имеет.

Коллекция - свойство объекта, который может иметь более одного значения. свойствами в Cache' могут быть: литеральные типы данных (атомарное значение, как в РСУБД), ссылки на другие объекты, встроенные объекты, потоки. Соответственно, коллекция это тоже свойство, только может иметь более одного значения.

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

Ну в общем если пренебречь разницей в терминологии, то пока - весьма похоже.
15 мар 05, 19:42    [1388346]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
2 Andreww:

Оптимизатор есть, Cost-Based. Это если смотреть на данные со стороны SQL.

Что касается гибкости - Cache' (для некоторых задач) позволяет физически организовать хранение данных более эффективным образом, нежели РСУБД.

Если вернутся к примеру с Parent-Child отношением то в РСУБД это как минимум две таблицы и любой запрос - это Join (не суть важно как он будет выглядеть на уровне синтаксиса, важно что СУБД нужно будет прочитать данные из двух _физически_ разных мест базы). В Cache', да, полагаю, и в Versant тоже эти данные _физически_ хранятся вместе - читай - не требуют меньше обращений к диску.

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

Откуда: Москва
Сообщений: 913
Что представляет собой в Cache уникальный объектный идентификатор? И как система ищет нужный объект по ссылке, если этот объект не хранится рядом с объектом, содержащим эту ссылку в качестве атрибута ?
15 мар 05, 20:00    [1388381]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
Alexey Rovdo
Что представляет собой в Cache уникальный объектный идентификатор? И как система ищет нужный объект по ссылке, если этот объект не хранится рядом с объектом, содержащим эту ссылку в качестве атрибута ?


Объект уникально определяется по имени класса, к которому он принадлежит плюс идентификатору. Идентификатор - любое свойство/(набор свойств) объявленное при создании класса первичным идентификатором объекта. Чаще всего используется создоваемое по умолчанию id - автоинкремент.

Если речь идет о наследовании - идентификатор определяется один раз в базовом классе, все подклассы его наследуют и по нему не пересекаются. Например, Пионер и Пенсонер - наследники класса Человек. Не может быть одновременно и пионера и пенсионера с id=10. Экземпляры Пионеров и Пенсионеров будут хранится вместе. Тамже где и "просто Человеки".
15 мар 05, 20:11    [1388410]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 aou

>>Оптимизатор есть, Cost-Based. Это если смотреть на данные со стороны SQL.

И статистика считается ? Можно ссылочку на Features этого оптимизатора (действительно интересно) ?

>>Что касается гибкости - Cache' (для некоторых задач) позволяет физически организовать хранение данных более эффективным образом, нежели РСУБД.

Вроде же мы выяснили, что РСУБД умеют хранить данные в B*tree или вы не согласны ?

Для некоторых случаев это действительно выгодно, только случаев таких очень немного.

>>Если вернутся к примеру с Parent-Child отношением то в РСУБД это как минимум две таблицы и любой запрос - это Join (не суть важно как он будет выглядеть на уровне синтаксиса, важно что СУБД нужно будет прочитать данные из двух _физически_ разных мест базы). В Cache', да, полагаю, и в Versant тоже эти данные _физически_ хранятся вместе - читай - не требуют меньше обращений к диску.

Вы действительно полагаете, что :

1 СУБД читает блоки диска строго по одному
2 После многочисленных операций удаления\вставки все блоки данных по прежнему будут "храниться вместе"
3 Операция изменения данных которые "_физически_ хранятся вместе" незатратна и проста в реализации
4 СУБД всегда обслуживает только одного пользователя и не выполняет по нескольку операций чтения\поиска\записи на одном и том же устройстве для разных пользователей
5 Возможность алгоритмически уменьшить число обращений к диску (оптимизатором) не так эффективна "хранение данных вместе"
6 Любые данные можно представить в виде дерева (Parent-Child)

Если да, то мне кажется ваши представления об устройстве СУБД не совсем верны.

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

Можете привести примеры "более эффективные структуры", кроме "_физически_ хранятся вместе", эффективность которых, мягко говоря, сомнительна ?
Или расскажите как преодолеть трудности которые я привёл выше (6 пунктов).
15 мар 05, 20:21    [1388428]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

С точки зрения практики - ерунда.

Как быть тогда с тезисом, что нет ничего практичней хорошей теории? Считать этот тезис абсолютно неверным? Практическая польза от теорий не возможна?

Alexey Rovdo

Главное, чтобы работало и решало все поставленные задачи качественно и надежно!


Много требований, которым на первый взгляд теория не повредит.

Alexey Rovdo

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

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

Alexey Rovdo

Возможно это и приведет к каким-то заметным результатам в будущем.

Стараюсь следить за этим. В том числе и с Вашей помощью.

Alexey Rovdo

. Уже давно публично признана и проблема "несоответствия импедансов" (impedance mismatch), проявляющаяся на стыке реляционной БД и ОО-приложения.

Это, я так понимаю, недостаток ОРМД? Поподробнее если можно осветите вопрос. В чем он? Насколько критичен? Ставит ли, по Вашему, крест на ОРСУБД. ОРСУБД - тоже входит в эту тему.


Alexey Rovdo

Развитие таких ОО-языков как Java, C++, C# только еще больше высвечивает этот аспект, вынуждая разработчиков искать хоть какие-то альтернативы реляционным хранилищам.

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

Alexey Rovdo

И именно ООСУБД сегодня такие альтернативы предлагают.


Несомнено. Но какие? Хоть какие-то или все-таки что? Вот это мы здесь и пытаемся прояснять.

Alexey Rovdo

Но, например, самая большая в мире база данных SLA построена на базе ООСУБД.

Очень интересная инфа. Я не видел про самую большую нигде. Как определено и кем подтверждено, что самая большая? Какая СУБД? Подробности любые интересны.

Alexey Rovdo

В военной сфере ООСУБД всегда применялись весьма активно. В бионформатике и генетическом анализе им практически нет альтернативы сегодня. Телекоммуникации — достаточно широкая и разнообразная сфера, но в ней также есть сегменты, в которых ООСУБД всегда были сильны и очень популярны.

В этих областях какое соотношение? Вы сказали что в общем на порядок у РСБД больше рынка. А как здесь?

Alexey Rovdo

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

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

Alexey Rovdo

Все это в равной мере можно распространить и на реляционные, и на объектные системы.

Распространить можно. Но как Вы упоминали, имеет значение доля рынка и способность тех или иных типов СУБД захватить основную долю рынка. Нас то с Вами интересует основная доля рынка? А не 5 - 6 %? Пусть остаются за устаревшими системами. Для меня важно скока будет занимать РСУБД или ОРСУБД, и в них моя СУБД, а для Вас ООСУБД и среди них Версант.
Не так ли?
15 мар 05, 20:45    [1388461]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
aou
Member

Откуда:
Сообщений: 37
2 Andreww :

И статистика считается ? Можно ссылочку на Features этого оптимизатора (действительно интересно) ?

Считается.

Вроде же мы выяснили, что РСУБД умеют хранить данные в B*tree или вы не согласны ?

Кто бы спорил! Другое дело что РСУБД в этих структурах может хранить _только_ таблицы c атомарными атрибутами (детали о хеш таблицах и кластерных индексах пока опустим). Грубо говоря - только записи с литеральными типами данных. Опять таки, есть исключения типа объектных надстроек Oracle. Cache' может в B*-tree хранить и коллекции и встроенные объекты и отношения.

Для некоторых случаев это действительно выгодно, только случаев таких очень немного.

Ну количественную оценку мы с вами врядли здесь получим. Скорее здесь будет играть роль опыт конкретного разработчика и инструмент, с которым он привык работать.

Вы действительно полагаете, что :

1 СУБД читает блоки диска строго по одному

Блок - единица обмена информацией между диском и памятью. Действительно существуют алгоритмы оптимизации (например - упреждающее чтение), при которых за одну операцию с диска считывается несколько блоков. Очень интересный материал от Microsoft был на последней конференции WLDB по Write Optimized B-Tree http://www.vldb.org/conf/2004/RS18P2.PDF Но сути дела это не менят. Мы либо читаем/пишем весь блок целиком, либо нет.

2 После многочисленных операций удаления\вставки все блоки данных по прежнему будут "храниться вместе"

Конечно нет. См. Google, B-Tree, Block Split.

3 Операция изменения данных которые "_физически_ хранятся вместе" незатратна и проста в реализации

Не понял вопроса. Если вы про обеспечение конкурентного доступа, то в Cache' эта задача решена на уровне логических блокировок.

4 СУБД всегда обслуживает только одного пользователя и не выполняет по нескольку операций чтения\поиска\записи на одном и том же устройстве для разных пользователей

С чего вы взяли что я так полагаю? Большинство СУБД (Cache' не исключение) как раз позволяют одновременно обрабатывать конкурирующие запросы.

Другое дело что в случае _одного_ устройства мы за частую ограничены тем самым устройством, которое в состоянии в отдельновзятый момент времени совершать ровно одну операцию ввода-вывода.


5 Возможность алгоритмически уменьшить число обращений к диску (оптимизатором) не так эффективна "хранение данных вместе"

Почемуже. Эффективно и то и другое. Неправ тот кто полагается только на оптимизатор также как и тот, кто его игнорирует, пологаясь только на дизайн.

6 Любые данные можно представить в виде дерева (Parent-Child)

Чисто теоретически - верно. Точно также как верна и реляционная теория, которая утверждает что любую модель можно представить как совокупность плоских таблиц.

Но я ни в коем случае не заявляю что пользоватся нужно только Parent-Child! В Cache' во многих случаях уместен будет разумный компромис. В РСУБД, увы - только таблицы.

Если да, то мне кажется ваши представления об устройстве СУБД не совсем верны.

Надеюсь, сумел вас хоть немного разубедить.

Если еще захочется позадавать вопросы - буду очень признателен если прочитаете для начала хотябы вот это: http://www.intersystems.com/cache/technology/techguide/index.html

Вот документация: http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls

Особенно полезно будет пара документов вот отсюда: http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=SETAppDev см. Using Cache' SQL и Using Caché Multi-Dimensional Storage
15 мар 05, 22:08    [1388533]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

На самом низком уровне данные хранятся в блоках по 8к. Объект - "ребенок" хранится вместе с объектом "родителем", но если объем данных так или иначе перейвалит отметку в 8к - есть шанс что "ребенок" попадет не в тотже, а в соседний блок. (Почуствуйте разницу с двумя принципиально разными таблицами в РСУБД)

Вообще то у Оракла есть понятие кластера (группа таблиц), который обеспечивает механизм хранения в одном блоке записи из разных табл. Хранение группы таблиц, имеющих один или несколько общих столбцов, в одних и тех же блоках БД, так что взаимсвязанные данные хранятся в одном блоке. Есть и Hash clusters. Если известно, что таблы участвуют в соединениях между собой, то можно рассматривать подобные возможности.

Т.е. разницу почувствовать пока еще не удалось, возможно потому, что это скорее физический аспект, чем логический. РМД - никак не ограничивает использование подобных решений.
В ней ничего не говорится про блоки, файлы, кеши и проч и их использование.
И нет явных каких-то противопоказаний против тех или иных решений на физическом уровне. Это скорей вопрос реализации конкретной СУБД и ее фич.
16 мар 05, 00:32    [1388595]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Alexey Rovdo

>Я из вашего пространного поста, что ООСУБД и РСУБД сравнивать нельзя ни по каким критериям, поскольку они несравнимы.

Смысла этого предложения я не понял, но это не важно.

Вы постоянно уходите от от ответов на конкретные вопросы. Их было задано 2, вот они (c127, [1385017]):

1) ... предложите ... КОНКРЕТНЫЙ способ сравнения "объектно-ориентированных, реляционных и объектно-реляционных СУБД".

2) Видимо есть серьезные причины избегать версанта. Расскажите о них.

Последнее касается того удивительного факта, что Вы пропагандируете Версант, но сами избегаете его использовать. Эта информация может оказаться полезной при сравнении ООБД и РСУБД.
16 мар 05, 01:52    [1388618]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

Мне кажется вы торопитесь делать выводы. Например ваш (вполне уместный) список замечаний к описанию Cache:

Andreww

1 СУБД читает блоки диска строго по одному
2 После многочисленных операций удаления\вставки все блоки данных по прежнему будут "храниться вместе"
3 Операция изменения данных которые "_физически_ хранятся вместе" незатратна и проста в реализации
4 СУБД всегда обслуживает только одного пользователя и не выполняет по нескольку операций чтения\поиска\записи на одном и том же устройстве для разных пользователей
5 Возможность алгоритмически уменьшить число обращений к диску (оптимизатором) не так эффективна "хранение данных вместе"
6 Любые данные можно представить в виде дерева (Parent-Child)


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

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

1) ... предложите ... КОНКРЕТНЫЙ способ сравнения "объектно-ориентированных, реляционных и объектно-реляционных СУБД".


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

c127

2) Видимо есть серьезные причины избегать версанта. Расскажите о них. Последнее касается того удивительного факта, что Вы пропагандируете Версант, но сами избегаете его использовать.


Нет таких причин. И я нигде ничего подобного не говорил.
16 мар 05, 11:31    [1389627]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
aou
Alexey Rovdo
Что представляет собой в Cache уникальный объектный идентификатор? И как система ищет нужный объект по ссылке, если этот объект не хранится рядом с объектом, содержащим эту ссылку в качестве атрибута ?


Объект уникально определяется по имени класса, к которому он принадлежит плюс идентификатору. Идентификатор - любое свойство/(набор свойств) объявленное при создании класса первичным идентификатором объекта. Чаще всего используется создоваемое по умолчанию id - автоинкремент.

Если речь идет о наследовании - идентификатор определяется один раз в базовом классе, все подклассы его наследуют и по нему не пересекаются. Например, Пионер и Пенсонер - наследники класса Человек. Не может быть одновременно и пионера и пенсионера с id=10. Экземпляры Пионеров и Пенсионеров будут хранится вместе. Тамже где и "просто Человеки".


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

В Cache, судя по вашему описанию, прямая навигация по ссылкам будет работать медленнее по следующим причинам. Для нахождения искомого объекта СУБД должна произвести поиск объекта с заданым ID во множестве объектов известного класса (ID не содержит физический адрес объекта). Разумеется, существуют методы для ускорения такого поиска (индексы, кластеризация), но сам поиск как таковой все равно неизбежен. Собственно, именно в этой особенности и состоит отличие Cache от истинно объектных СУБД (к коим и относятся СУБД FastObjects и Versant Developer Suite), которые заточены именно для прямой навигации по объектным ссылкам.

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

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

Что же касается выводов, то замечу - Cache явно идет дальше типичного реляционного подхода к хранению данных и вводит ряд механизмов для поддержки ОО-структур (кластеризация по классам, поддержка наследования, кластеризация по связи с корневым объектом, полагаю также, что может быть и кэширование на уровне объектов). Но похожие механизмы сегодня есть у большинства т.н. ОРСУБД, к которым можно отнести и Oracle, и PostgreSQL и др. Несомненно, такие механизмы облегчают реализацию и ускоряют работу ОО-приложений на базе указанных СУБД, но они никак не позволяют называть все эти СУБД объектно-ориентированными. Между ООСУБД и РСУБД существуют концептуальные различия, которые просто не позволяют в одном продукте совместить эти концепции чем-то не пожертвовав.
16 мар 05, 11:57    [1389818]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 aou


>>И статистика считается ? Можно ссылочку на Features этого оптимизатора (действительно интересно) ?

>Считается.

Ну ссылочку, конкретно на оптимизатор и статистику можно ?


>>Кто бы спорил! Другое дело что РСУБД в этих структурах может хранить _только_ таблицы c атомарными атрибутами (детали о хеш таблицах и кластерных индексах пока опустим). Грубо говоря - только записи с литеральными типами данных. Опять таки, есть исключения типа объектных надстроек Oracle. Cache' может в B*-tree хранить и коллекции и встроенные объекты и отношения.

>>Для некоторых случаев это действительно выгодно, только случаев таких очень немного.

>>Ну количественную оценку мы с вами врядли здесь получим. Скорее здесь будет играть роль опыт конкретного разработчика и инструмент, с которым он привык работать.

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

Начать лучше отсюда - https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=20#1126083

Если день всё читать (а там много интересного, но есть и "юморески" коллеги ЧАЛ-а) можно прочитать просто :

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=20#1126083

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=11#1117520

Прочитайте, действительно многое прояснится. Жаль что мой диалог с г-ном Gluk, прервался, было интересно.

Теперь вернёмся к нашим баранам


>>1 СУБД читает блоки диска строго по одному

>Блок - единица обмена информацией между диском и памятью. Действительно существуют алгоритмы оптимизации (например - упреждающее чтение), при которых за одну операцию с диска считывается несколько блоков. Очень интересный материал от Microsoft был на последней конференции WLDB по Write Optimized B-Tree http://www.vldb.org/conf/2004/RS18P2.PDF Но сути дела это не менят. Мы либо читаем/пишем весь блок целиком, либо нет.

Вот именно ! И упреждающие чтение далего не единственный алгоритм. Система пытается прочесть сразу некоторую ПОРЦИЮ информации, и как в ней располагаются данные вместе или порознь это не важно.

>>2 После многочисленных операций удаления\вставки все блоки данных по прежнему будут "храниться вместе"

>>Конечно нет. См. Google, B-Tree, Block Split.

Подозреваю, что я читал про расщепление узлов, когда все его называли преемущественно расщепление узлов, а не Block Split.
Googlе-а тогда тоже не было. Прочитайте ссылки которые я вам приводил. И опыт реализации Б-дерева у меня был, правда небольшой :(

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

Вроде получилось.


>>3 Операция изменения данных которые "_физически_ хранятся вместе" незатратна и проста в реализации

>>Не понял вопроса. Если вы про обеспечение конкурентного доступа, то в Cache' эта задача решена на уровне логических блокировок.

Более-менее внятно пытался объяснить тут - https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=11#1117520


>>4 СУБД всегда обслуживает только одного пользователя и не выполняет по нескольку операций чтения\поиска\записи на одном и том же устройстве для разных пользователей

>>С чего вы взяли что я так полагаю? Большинство СУБД (Cache' не исключение) как раз позволяют одновременно обрабатывать конкурирующие запросы.

Опять же. Если одновременно обрабатываются несколько конкурирующих запросов, вся выгода от "хранения данных вместе" исчезает, т.к. конкурирующие запросы скорее всего будут состоять из запросов к данным которые находятся в другом месте жёсткого диска.
И 90 % времени дисковая подсистема будет тратить на позиционирование.

>>Другое дело что в случае _одного_ устройства мы за частую ограничены тем самым устройством, которое в состоянии в отдельновзятый момент времени совершать ровно одну операцию ввода-вывода.

Безусловно так.

>>5 Возможность алгоритмически уменьшить число обращений к диску (оптимизатором) не так эффективна "хранение данных вместе"

>>Почемуже. Эффективно и то и другое. Неправ тот кто полагается только на оптимизатор также как и тот, кто его игнорирует, пологаясь только на дизайн.

Выводы про это нужно было сделать позже.


>>6 Любые данные можно представить в виде дерева (Parent-Child)

>>Чисто теоретически - верно. Точно также как верна и реляционная теория, которая утверждает что любую модель можно представить как совокупность плоских таблиц.

Теоретически верно ? И доказательство есть ? Практически - процент таких данных очень мал. Кстати, в реляционной теории нет понятия таблица, реляционная теория не оперирует таблицами, ни плоскими ни круглыми.

>>Но я ни в коем случае не заявляю что пользоватся нужно только Parent-Child! В Cache' во многих случаях уместен будет разумный компромис. В РСУБД, увы - только таблицы.

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

Какие из этого выводы :

Хранение данных "физически вместе" если даст выигрыш, то незначительный, а может привести и к потере производительности.
Так как :

1. Система пытается прочесть сразу некоторую ПОРЦИЮ информации, и как в ней располагаются данные вместе или порознь это не важно.

2. После некоторых операций удаления\вставки блоки перестанут "физически хранится вместе" и избежать этого (не теряя производительности) не удастся.

3. Для структур типа B*-tree операции в многозадачной среде или весьма затратны или приводят к потере балланса дерева.

4. Если одновременно обрабатываются несколько конкурирующих запросов, вся выгода от "хранения данных вместе" исчезает.

6. Совсем не всегда данные можно представить в виде дерева (Parent-Child).

А тепер 5-ый (прошу прощени за сумбур) :

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

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


>>Если еще захочется позадавать вопросы - буду очень признателен если прочитаете для начала хотябы вот это: http://www.intersystems.com/cache/technology/techguide/index.html

Верите, читал, даже на Cache смотрел, пока жизнь не заставит буду держаться от устаревшей иерархической концепции в новой блестящей "объектной" обёртке как можно дальше.

>>Вот документация: http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls

Видел, даже скачал. :)

>>Особенно полезно будет пара документов вот отсюда: http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=SETAppDev см. Using Cache' SQL и Using Cache' Multi-Dimensional Storage

Забавно, а такую ссылочку видали - http://www.dbdebunk.com/page/page/622930.htm .

Что-то создатели КАШЕ больше похожи на "плавающего" на экзамене студента.
16 мар 05, 12:28    [1390057]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 51 52 53 54 55 [56] 57 58 59 60 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить