Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
_мод
Guest
недостатки иерархических

В PCB в IMS задается путь (from) и условие (where) - аналог SQL запроса.
А VSAM - это почти РСУБД. В IMS в иерархии только один индекс, который и образует иерархию. То же самое и в мумпсе.
25 июн 08, 16:18    [5847039]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Favn

Классическая иерархическая несколько устарела (лет так на 30 :) )
...
Недостатки, на вскидку:
1. Отсутствует декларативный язык запросов (SQL). Логику работы с данными приходится реализовывать в программах => она неизменна и почти не масштабируется.
2. Следствие - при изменении БД надо менять программы, для эффективной работы необходимы хорошие программисты :), т.к. языки процедурные.
3. Еще следствие - процедурный запрос почти не параллелится => никакая масштабируемость.
4. В тех СУБД, где внешний SQL есть (Cache, Titanium) - он скуден, требуется ручное сложное проектирование отображения родной сетевой структуры в реляционную. Плохие оптимизаторы SQL.
5. нет стандарта на процедуру доступа к иерархическим данным, как следствие знания программиста в "иерархическом"-QL не переносятся между ИСУБД.

6. отсутствие единого стандарта (даже на минимальном уровне) означает практическую не переносимость приложений между ИСУБД. приложение написанное с использованием базового SQL можно перенести на другую СУБД.
25 июн 08, 16:29    [5847138]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
а как там у иерархических с изолированностью транзакций ? какие-то транзакции и блокировки в каше помнится были, но смутно помню что блокировками нужно было вручную шаманить, чтоб не нарваться на феномены описанные в ansi sql стандарте.
25 июн 08, 16:36    [5847195]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
На сетевые стандарт есть - CODASYL. Другое дело, что уже почти нет никого, кто ему когда-то следовал :)

Yo.!
а как там у иерархических с изолированностью транзакций?
Из не-реляционных когда-то работал только с Titanium, на CODASYL построенном. Там наборы и отношения примерно соответствуют реляционным кортежам (записям), так что он похож на обычный блокировочник на уровне до записи (или до группы записей, для многие-ко-многим).
25 июн 08, 16:52    [5847358]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
Favn
Из не-реляционных когда-то работал только с Titanium, на CODASYL построенном. Там наборы и отношения примерно соответствуют реляционным кортежам (записям), так что он похож на обычный блокировочник на уровне до записи (или до группы записей, для многие-ко-многим).

т.е. если выставлен уровень изолированности serializable он при чтении автоматически будет расставлять шаред блокировки (на что ?) и не забудет их снять, а при read committed будет вести себя совершенно по другому ?
25 июн 08, 17:11    [5847530]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
Ну откуда там serializable? Оно ж не Oracle :)
Насколько я помню, а дело было лет 10-12 назад, в Titanium блокировки примерно соответствовали уровню CR. Атомарными объектами в CODASYL являются наборы, т.е. "справочники" в реляционках и отношения, т.е. "таблицы связей" 2-х наборов друг с другом, прошу пардону за вульгаризмы для РСУБД. Соответсвенно, транзакция блокирует до 1-й записи набора и до 1-й записи отношения (может связывать группу записей из 2-х наборов). Кстати, по наборам строятся как иерархические, так и хеш-индексы.
25 июн 08, 17:24    [5847636]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
1) Отсутсвие стандарта на язык доступа к данным.
2) императивный, навигационный язык БД.
3) Большая зависимость приложений от данных в иерахических БД по сравнению с РСУБД
4) Отстутсвие оптимизатора, что приводит к программированию в клиентах низкоуровневых методов доступа. Что тоже не облегчает изменение структуры данных.
5) Нет возможности имлементировать бизнес логику в базе данных

Так пункт 3) нормально?

Что по пункту 4)? Просто - отсутсвие оптимизатора? Его ведь действительно нет. Что это значит, что его нет?

Favn - что-то не убедительно про процедурный доступ к данным. Явно, привязано к какой-то конкретной реализации. Может, конкретный пример что-то прояснит, но это ведь от реализации зависит.

_mod - а точно, в IMS только один индекс, который и образует иерархию? Или вы вспоминаете?
Ч трудом представляю себе, что мешает реализовать в IMS поддержку нескольких индексов, если уж в VSAM это не проблема. интересно, каким боком VSAM это RDBMS ? Я без стёба, на польном серйозе - никогда таких ассоциаций не возникало.

Можно добавить пункт 6) - про уровни изоляций. С изоляцией транзакций проблем нет, а вот про уровни изоляций - можно константировать, что их нет. Я прав? Есть один уровень - нужные данные или заблокированы, или доступны. Принципиальных отличий от реализации совместного доступа, например, у VSAM и IMS я не вижу.
25 июн 08, 17:34    [5847723]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
Favn
Ну откуда там serializable? Оно ж не Oracle :)
Насколько я помню, а дело было лет 10-12 назад, в Titanium блокировки примерно соответствовали уровню CR. Атомарными объектами в CODASYL являются наборы, т.е. "справочники" в реляционках и отношения, т.е. "таблицы связей" 2-х наборов друг с другом, прошу пардону за вульгаризмы для РСУБД. Соответсвенно, транзакция блокирует до 1-й записи набора и до 1-й записи отношения (может связывать группу записей из 2-х наборов). Кстати, по наборам строятся как иерархические, так и хеш-индексы.

то что далеко до уровня оракла и его MVCC никто не сомневается, интересно супртив хотя бы MSSQL2k. а какие виды блокировок там были ? shared к примеру были, при которых можно читать, нельзя модифицировать ? вообще у современного блокировочника десятки блокировок (типа намерений, диапозона, на апдей), которыми руками управлять наверно совсем весело.

ЗЫ. т.е. гемморой в виде ручного управления блокировками для получения хотя бы консистентного набора как пунктик записать уже можно.
25 июн 08, 17:49    [5847854]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
недостатки иерархических
_mod - а точно, в IMS только один индекс, который и образует иерархию? Или вы вспоминаете?

Это природное св-во ИСУБД - один индекс по иерархии - тем самым обеспечивается быстрый доступ, но только по главному индексу. Чтобы это как-то исправить в IMS ввели возможность связывать разные иерархии в сеть - получаются дополнительные индексы.
зы Если много разных индексов - то это уже не ИСУБД - это сетевые (типа adabas)
25 июн 08, 17:53    [5847904]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
_mod - не хочу ссылаться на доку, наверное, и сами способны, но у того же IMS существует понятия secondary index, который не имеет ничего общего с logical reference, который между иерархиями, и который собственно преобразует иерархическую IMS в сетевую. Но даже в этом случае, приложение работает не с сетевой моделью, а строго с иерархической - физический родитель -> логический потомок.
И никакой сети. Именно по-этому IMS и является иерархической (по названию) до сих пор. Если верить IBM.
Опять же, иерархия в IMS задаётся отнюдь не индексами. Ничего общего с индексами она не имеет. И среди множества методов доступа IMS есть и такие, которые не подразумевают наличие индекса даже ждя root segment, если я не ошибаюсь.
Я так и не понял, зачем вы связали вместе один и только один индекс в иерархической базе данных.
Кстати, именно наличие в том числе secondary indexes (плюс, само собой, logical references) даёт некое наличие декларативности в SSA - приложение, используя SSA в DL/I просто декларирует, что вернуть все записи, где, например, FIELD1>='VALUE'
И здесь нету никакого "зашития физического низкоуровневого доступа" в код приложения.

По поводу блокировок - Yo.! , я же уже писал, что, например, со времён VSAM нету ручного управления блокировками. Нету их и в некоторых реализациях иерархических баз (mumps, пожалуста, не предлагать - одна из реализаций). Более того, logical references (ссылки между иерархиями) в реализации той же IMS тоже управляются базой, как и индексы. Если это не так в mumps, тем хежу для него.
25 июн 08, 18:05    [5848012]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
кстати, _mod, я сразу не заметил.
"where" (в терминологии IMS это SSA) определяется не в PCB, а как аргумент DL/I вызова.
То же самое и по отношению к "from" (в терминологии IMS это segment name, насколько я понимаю).
то есть аналогия с параметризованным sql
25 июн 08, 18:18    [5848104]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
недостатки иерархических

По поводу блокировок - Yo.! , я же уже писал, что, например, со времён VSAM нету ручного управления блокировками. Нету их и в некоторых реализациях иерархических баз (mumps, пожалуста, не предлагать - одна из реализаций). Более того, logical references (ссылки между иерархиями) в реализации той же IMS тоже управляются базой, как и индексы. Если это не так в mumps, тем хежу для него.

насколько я помню VSAM вообще не было понятия блокировки, были какие-то блокировки на уровне ОС которая пыталась сериализовать поток писанины VSAM в файлик, но они не были дотупны приложению. разве не так ?
25 июн 08, 18:49    [5848246]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Не совсем так. Просто однозначно в этой платформе сказать нельзя. Это у вас дар однозначно давать оценки - оракл хорошо, остальное плохо.
Да, многие софтины в MVS пользуются ресурсом операционки. Да, операционка в этом во многом полагается на железо. Именно из-за того, что и hardware, и операционку, и software контролирует один поставщик, то при всех недостатках этого (вы их легко придумаете) наблюдаются и достоинства.
И таки совместная транзакционная работа с VSAM наборами имеет место быть, и на разных машинах тоже (хотя вам и не нравиться думать, что Syspex не может работать на 100 км, он таки да, работает)
И cost based оптимизатор у IBM старейший в индустрии, а не у оракл.
И Shared memory DB2 прекрасно использует.
Просто в вашу картину мира это не вписывается. Но это ваша проблема.

Давайте вернёмся к недостаткам иерархических баз.

Принимаем окончательную версию

1) Отсутсвие стандарта на язык доступа к данным.
2) императивный, навигационный язык БД.
3) Большая зависимость приложений от данных в иерахических БД по сравнению с РСУБД
4) Отстутсвие оптимизатора, что приводит к программированию в клиентах низкоуровневых методов доступа. Что тоже не облегчает изменение структуры данных.
5) Нет возможности имлементировать бизнес логику в базе данных
6) Отсутсвие стандартных уровней изоляции транзакций.

Пункт 6) добавлен по наводке Yo.! и мне кажется, что это действительно так.
Или ещё будут правки/дополнения?
25 июн 08, 20:08    [5848496]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
недостатки иерархических
Не совсем так. Просто однозначно в этой платформе сказать нельзя. Это у вас дар однозначно давать оценки - оракл хорошо, остальное плохо.
Да, многие софтины в MVS пользуются ресурсом операционки. Да, операционка в этом во многом полагается на железо. Именно из-за того, что и hardware, и операционку, и software контролирует один поставщик, то при всех недостатках этого (вы их легко придумаете) наблюдаются и достоинства.

куда соскакиваешь, раз уж пришел защищать этот хлам - давай копаться до конца. если приложение не может поставить блокировку, а ОСь не в курсе хотелок приложение то на выходе принципиальная не возможность получить элементарного - к примеру невозможно получить консистентный набор.
25 июн 08, 20:23    [5848523]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Favn
Если однотипные документы XML формализованы схемамой, то она как раз описывают структуру документов, включая типы полей. Это используется при хранении и обработке. И схемы задают структуру БД, и изменение схемы может сделать документы невалидными.

Возможно, в конкретной реализации СУБД может не полностью использованы возможности XML модели? Вот открыл источник "Системы баз данных" Гектор Гарсиа-Моллина и др.:
"...модель полуструктурированных данных не укладывается в рамки какой бы то ни было схемы. Данные сами по себе несут информацию о том, как их следует представлять, и подобная "схема" способна изменяться произвольно, как со временем, так и в контексте базы данных".


Favn
Логически вытекает из процедурности извлечения данных - грубо говоря, зашитые в программу циклы сервер не разобъет по разным потокам.

Но надо доказать теоретически, что не может, быть предоставлен механизм для многпоточности проггерам, ить процедуры пишут проггеры. Так или иначе это все же как бы вопросы реализации МД.
25 июн 08, 20:27    [5848534]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
недостатки иерархических
Принимаем окончательную версию

1) Отсутсвие стандарта на язык доступа к данным.
2) императивный, навигационный язык БД.
3) Большая зависимость приложений от данных в иерахических БД по сравнению с РСУБД
4) Отстутсвие оптимизатора, что приводит к программированию в клиентах низкоуровневых методов доступа. Что тоже не облегчает изменение структуры данных.
5) Нет возможности имлементировать бизнес логику в базе данных
6) Отсутсвие стандартных уровней изоляции транзакций.

Пункт 6) добавлен по наводке Yo.! и мне кажется, что это действительно так.
Или ещё будут правки/дополнения?

Пункты 1)-3) соответсвуют известным из литры. пп 4) и 5) - не понятка.
пп 6) есть уверенность что это обусловленно самой ИМД? Вроде как читал, что на это МД как правило не накладывают ограничения. Это типа дела СУБД.
25 июн 08, 20:33    [5848547]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
Дайте ссылку, кто из форумчан больше всего повлиял на ваши выводы. Хочу прочитать внимательнее.
недостатки иерархических
1) Отсутсвие стандарта на язык доступа к данным.
Языки XQuery/XPath претендуют как стандарт на язык доступа, а XML на представление иерархических данных.
недостатки иерархических
2) императивный, навигационный язык БД.
XQuery/Xpath – декларативные языки
недостатки иерархических
3) Большая зависимость приложений от данных в иерахических БД по сравнению с РСУБД
Зависимость та же, что и в РСУБД
недостатки иерархических
4) Отстутсвие оптимизатора, что приводит к программированию в клиентах низкоуровневых методов доступа. Что тоже не облегчает изменение структуры данных.
Необходимость оптимизатора связано со слабостью реализации.
недостатки иерархических
5) Нет возможности имлементировать бизнес логику в базе данных
Бизнес логика может быть та же, что и в реляционных моделях. Иерархические структуры легко трансформируются в реляционные и наоборот.
Реляционная модель
A  B  C
a1 b1 c1
a1 b2 c1

B  D
b1 d1
b2 d2

C  E
c1 e1

Класс-реляционная модель
 A
/  \
B  C
|  |
D  E

   a1
/   |  \
b1 b2  c1
|   |   |
d1 d2  e1
25 июн 08, 20:47    [5848591]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
недостатки иерархических
Favn - что-то не убедительно про процедурный доступ к данным. Явно, привязано к какой-то конкретной реализации.

vadiminfo
Но надо доказать теоретически, что не может, быть предоставлен механизм для многпоточности проггерам, ить процедуры пишут проггеры. Так или иначе это все же как бы вопросы реализации МД.
Я не говорил, что масштабируемости нет, я говорил, что она плохая. Во всех иерархических-сетевых DML есть фактически набор API для внешнего универсального языка, с функциями типа "найти запись" - "найти потомков/родителей". Соответственно, любая обработка сводится к написанию программы, дергающей эти функции. Программа эта внешняя отн. сервера, т.е. сервер распараллелить выборку данных для этой программы не может никак, если сама программа внутри не параллелится. То есть, праллельное выполнение возможно только для нескольких приложений, но не внутри одного (однопоточного).
25 июн 08, 21:06    [5848620]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
полкз копапатся, надо же какой прогрес:

You open a VSAM cluster in RLS mode by either specifying this in your program ACB macro, or by using the RLS JCL keyword. Options are

* RLS=NRI, No Read Integrity; the application will read every record, even records that are in use elsewhere
* RLS=CR, Consistent Read; the application will put a share lock on the record while reading and will not read records that are held for update by another user.
* RLS=CRE, Consistent Read Explicit; the application will hold a record it is reading until is issues a commit point. CRE only works with applications that log updates and use commits to manage transaction backout.

т.е. изолированность транзакций все же прикрутили на старости лет.
25 июн 08, 21:09    [5848630]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
2 All
Есть предложение - разобраться-таки, о каких именно СУБД мы говорим - их туча, моск путается.
1. Собственно иерархические, по которым стандарта нет, реализации сами по себе.
2. XML как иерархические в широком смысле - хоть по ним стандарт есть.
3. Расширение иерархических - сетевые. Стандартизованы CODASIL (Adabas, Titanium...), но существующие реализации стандарт расширяют.
4. Расширение сетевых - объектные (Cache, Titanium тот же...). Тут кто во что горазд.
Имеет смысл рассматривать (1,3), (2) и (4) отдельно.
25 июн 08, 21:15    [5848640]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
vadiminfo
Возможно, в конкретной реализации СУБД может не полностью использованы возможности XML модели? Вот открыл источник "Системы баз данных" Гектор Гарсиа-Моллина и др.:
"...модель полуструктурированных данных не укладывается в рамки какой бы то ни было схемы. Данные сами по себе несут информацию о том, как их следует представлять, и подобная "схема" способна изменяться произвольно, как со временем, так и в контексте базы данных".
Я пишу на примере XML storage в DB2. Там если схема документов не задана, они действительно могут содеожать любой well-formed XML. Если же схема с описанием (в т.ч. типов полей) задана, хранятся они бинарно с учетом этой схемы, при вставке-правке на соответсвие схеме проверяются, и работа с ним становится эффективнее. Схемы документов входят в стандарты XML. Схемы отделены от данных (документов), и является такими же метаданными, как DDL в РСУБД.
25 июн 08, 21:23    [5848661]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
недостатки иерархических
Или ещё будут правки/дополнения?

На самом деле, если, например, отделять иерархические от сетевых (иногда под иерархическими понимают и те и другие, по историческому признаку), то в иерархических, например, не может быть потомков без предков. Хотя это может и можно обойти искуственно, задав пустых предков, но это явное усложнение моделированя (хотя с другой стороны ссылочная целостность обеспечивается автоматически). Слышал, что там какие-то траблы со связями многие ко многим.
В сетевых, конечно, это все можно.
При этом все структурированные МД имеют ограничения по моделировнию реального мира, так как оный может плохо влазить в жесткие структуры таких МД.
Потому когда Вы ставили вопрос о недостатках ИМД, возможно, надо уточнять по отношению к чему. Ну и плюс еще в общем сучае, те или иные особенности МД могут быть как недостаткми так и достоинствами.
25 июн 08, 21:30    [5848676]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
недостатки иерархических
1) Отсутсвие стандарта на язык доступа к данным.
2) императивный, навигационный язык БД.
3) Большая зависимость приложений от данных в иерахических БД по сравнению с РСУБД
4) Отстутсвие оптимизатора, что приводит к программированию в клиентах низкоуровневых методов доступа. Что тоже не облегчает изменение структуры данных.
5) Нет возможности имлементировать бизнес логику в базе данных
6) Отсутсвие стандартных уровней изоляции транзакций.
Пункт 6) добавлен по наводке Yo.! и мне кажется, что это действительно так.
Если забыть о XML
1) Скорее, фактическое отсутствие самого языка доступа. Как правило, DML в таких системах - просто API к внешнему унивесальному ЯП вида "найти сущность (по индексу)" - "найти ее родителей/потомков". Стандарт на сетевые есть, на остальные - нет.
2,3) DML встраивается во внешние ЯП, не абстрагируя (или абстрагируя слабо) данные от доступа к ним.
4) Было бы странно, если бы оптимизатор был - он априори имеет смысл только для декларативных языков. Как оптимизировать прописанный алгоритм, да еще внутри "чужого" языка? Недостаток - сама зашитая внутрь программы навигационность, что удорожает поддержку и требует более квалифицированного программирования.
5) Кое-где есть, но только на уровне SP (программ) на сервере, которые клиент может вызвать. То есть в зачаточном сотоянии. Опять-таки, в отсуттвие декларативности бизнес-логика в реляционном понимании теряет смысл.
6) Стандартных для РСУБД - нет. К тому же, и в РСУБД нет такого стандарта :) Вообще - у многих есть, похожие на блокировочные РСУБД.

Если кому интересно, есть до сих пор условно живая x86 CODASYL (с объектными и реляционными расширениями) СУБД Titanium.
25 июн 08, 21:48    [5848725]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Favn
Member

Откуда:
Сообщений: 585
Кстати, пришел в голову недостаток реляционных СУБД для моделирования иерархических структур - нативно поддерживается только один-к-одному. То есть, связь родитель-потомки не является атомарной сущностью (разбита на записи) и как минимум на уровне изоляции ниже cursor stability (2 Yo! - и уж тем более при версионности ;) ) консистентность не достигается.
25 июн 08, 22:01    [5848755]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Yo.! - прикрутили на старости лет - это в каком году?
Это так, чтобы расставить точки над i
Вы таки признаёте, что часто пукаете в лужу не подумав, и всё из-за твёрдолобости и упёртости, то есть "ВЕРЫ" в "святой и непогрешимый?
Но это к делу не относиться, просто не люблю безаппеляционные заявления, основанные не на знании, а на "вере" которая заменяет способность думать.
Естати, нет и мысли защищать иерархические базы данных. Есть мысль вычленить из мутного потока сознания, выданного такими как вы, крупицы истины - что же всё-таки в них есть недостатки, а что оголтелые обвинения недоучившихся Yo.!-шников.
А потом взять все эти недостатки, взять реализацию RDBMS и hierarchical DB, и реализовать одну и ту же коммерческую задачу на обих, прочувствовав недостатки на своей шкуре, и определив область применимости иерархических баз (прежде всего для себя лично определить), и степень влияния недостатков на применимость, а если общественности будет интересно, то записать и запостить то, что останеться в сухом остатке, как сугубо своё личное мнение, не претендующее на истину в последней инстанции.
Это было о целях.

odkoky - XQuery претендует на стандарт доступа к иерархическим базам данных? Это с каких пор, и к каким иерархическим базам данных? И что значит - претендует? Я не протестую, и не прикалываюсь - в той же IMS, которую _mod назвал "классической" иерархической, XML и XQuery реализованы легко и просто (в отличие от DB2, про остальных с грустью умолчим, пусть реализуют), но заявлять, что XQuery претендует на стандарт... Для этого надо на чём-то основываться. Вы на чём основываетесь, давая такое сильное утверждение, которое снимает основное (пункт 1)) возражение (недостаток) иерархических баз?
Xpath это подмножество XQuery, я бы их не разделял, а упоминал только XQuery, кстати, именно XPath "убирает" декларативность из XQuery, "привязывая" результат запроса к навигации - чуток не та структура документа, и мы получем национальное жилище индейцев, а не данные, которые ожидали - безо всякого предупреждения о не той структуре документа. SQL запрос к "не той" структуре данных просто не выполниться, насколько я понимаю, по причине отсутсвия поля ли, таблицы ли, и так далее.
Необходимость оптимизатора связана только с декларативностью, imho, и ни с чем больше. Про слабость реализации - не выдерживает никакой критики, и попахивает ЧАЛом - слабая реализация чего? в чём?
Я понимаю отсутсвие оптимизатора в той же IMS - он там просто не нужен. Грубо говоря, сценарий - если надо select bla, bla, bla from A inner join B where A.field_a=B.field_b, то в той же IMS два сценария - сегменты A и B связаны между собой ссылками (родитель/потомок) и задача тривиальна, или сегменты A и B никак не связаны, тогда надо написать программу, реализующую что? правильно, то же, что и оптимизатор. Но если ограничить область применения (OLTP) то если это надо сделать однажды, то значит
это надо сделать и со скоростью тысячи раз в секунду - то ситуация решается установлением связи и сведением проблемы к первому сценарию. Если же действительно всего один раз - то пишите программу.
Это я и называю недостатком? отсутсвие оптимизатора. В zig-zag не так? Поясните?
Имплементация бизнес-логики - я имел ввиду отсутсвие нечто подобного хранимим процедурам, сохранённым результатам запросов, тригеррам (может, и есть) и что там ещё.

vadiminfo - да, действительно, потомков без предков быть не может, но я в упор не вижу усложнения моделирования и необходимости в "пустых" предках. Да и сложности в реализации связи имногие ко многим не вижу, реализуется на удивление похоже на то, как в RDBMS ( я про IMS реализацию) imho.

Favn - не согласен по поводу вшитой навигационности - пример того же DL/I, который можно смело назвать пробразом SQL. Что-то читая доку не вижу там навигационности как обязательной.
Надо попросить Yo.! почитать, он там таких недостатков нароет, что вовек не разгребём :) Талант, одно слово.
И язык доступа есть - у кого какой, но есть.
И именно в той же IMS впервые возникла парадигма отделения доступа к данным от кода приложения - RDBMS не на пустой идее возникли, а Код таки в IBM работал, когда создал реляционную теорию.
Хотелось бы недостатков, а не мифов, об иерархических базах. А для перечисления недостатков нужны знания, а не слухи, почёрпнутые в том числе и из этого форума. Вот пункт 1) - ну самый что ни на есть объективный, ну нет стандарта, и всё тут...
25 июн 08, 22:27    [5848795]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить