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

Все xBase считаются реляционными :)
26 июн 08, 17:02    [5853938]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
_мод
Yo.!
к стате, а что такое фокспро 2.0 ? язык там нафигационный, SQLем не пахнет ...

Все xBase считаются реляционными :)

об том и речь, там есть таблички (файлики), есть реляции (типа references), но нет рел алгебры.
26 июн 08, 17:11    [5854030]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Yo.!
об том и речь, там есть таблички (файлики), есть реляции (типа references), но нет рел алгебры.

Ну да, модель отдельно - алгебра отдельно
26 июн 08, 17:24    [5854150]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
_мод
kdv
Сортировки могло и не быть, тогда бы сортировали на клиентской части. Разница по смыслу не велика.

Не торопитесь - без сортировки во вложенных запросах плохо. В том и дело, что сортировка - это уже часть модели.
Сортировки во вложенных запросах по факту - НЕТ. СУБД может игнорить эти команды поскольку на результирующий набор виляет только ORDER BY результирующего набора.
26 июн 08, 19:29    [5854868]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
_мод
Bogdanov Andrey
Никто не мешает вам ввести свой собственный термин, но для того чтобы быть понятым желательно все-таки использовать общепринятую терминологию.

Так и я об этом: в РМД - отношения, в СУБД - таблицы. Мы вроде обсуждаем СУБД, а не абстрактные МД.
Анализируется именно РМД и ИМД, иначе нужно переводить разговор на конкретные СУБД типа Oracle и CACHE.

А то рассматриваем конкретные РСУБД, и сравниваем с ИМД
26 июн 08, 19:31    [5854873]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Yo.! - ну давайте разберёмся.
Я учусь, здесь и сейчас, по-тому мне не трудно признаться, что я облажался, слил, пукнул в лужу, если я действительно был неправ и заблуждался, и в ходе дискуссии выяснилась истина.

Я утверждаю, что с времен VSAM (до RLS) небыло ручного управления блокировками.
Вы утверждаете, что она было именно ручное управление блокировками в VSAM.
Тогда надо выяснить, что такое ручное управление блокировками.

Есть куча opensource приложений, в которых нескольким процессам требуется доступ к одному и тому же ресурсу - файлу - и они используют самодельный протокол управления доступом к ресурсу. Каждому файлу, к которому нужен доступ, ставиться в соответствие lock файл, а приложение проверяет наличие этого lock файла, если есть - значит, кто-то уже работает с целевым файлом. И никто не может помешать приложению, не реализующему этот протокол, получить доступ к файлу.
Это я называю ручным управлением блокировками.

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

Я согласен признать, что я был неправ, и при доступе к VSAM используется ручное управление блокировками, если вы проясните мне принципиальную разницу между двумя случаями
1) с помощью enqueue приложение обращается к владельцу ресурса (OS) за блокировкой
2) с помощью select for update приложение обращается к владельцу ресурса (оракл) за блокировкой.

Или что положено юпитеру то не положено быку?
26 июн 08, 20:49    [5855028]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
Может, кто ткнёт носом в описание недостатков иерархических баз? Поиск по форуму и по инету дал мало вразумительного.
Только не недостатки Cashe и MUMPS, а иерархических баз, как класса.

Кодд хорошо описал эти недостатки. Чем базовая статья Кодда не годится?
Иерархическую организацию данных, по возможности, не следует использовать именно из-за этих недостатков. Поэтому MUMPS профессиональные разработчики и не используют никогда, как "иерархическую базу" на логическом уровне. А используют как уникальную интегрированную среду для реализации обычно объектных моделей данных.
Это, возможно, не очень хорошо понимается всеми. Отсюда и "скрытность" технологии. Которая проявляется даже в ее "новых" коммерческих названиях. Еще у Тютчева было такое стихотворение Cache-Cache, что переводится как "игра в прятки". А можно, при желании, еще язвительнее проинтерпретировать: Cache не в состоянии найти другую Cache, то есть сетевое взаимодействие не возможно): Вот примерно в таком духе и выступают "критики", не зная одну из сравниваемых технологий совершенно, и плохо (мягко говоря) понимая другую технологию):
26 июн 08, 21:05    [5855054]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
Может, кто знает ссылку на полемику Кода с сторонниками иерархических/сетевых баз?
Наверняка аргументы были сильны...

Была еще очень слабая, но очень часто упоминаемая, как сильная, статья Дейта про "вклад Кодда в великий спор". Неоднократно обсуждалась в этом разделе):
26 июн 08, 21:13    [5855068]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
А ссылку дать?
26 июн 08, 21:19    [5855084]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
vadiminfo
Николай1

Не понял.
А чем изменение представления принципиально отличается от изменения в программе?

Вам понравилось бы на авто в случае замены детали в двигателе еще и в трансмиссию лезть?

Ну, как же Вам не понятно?
1) Тем, что оно не в программе
Тем что нужны спецы не тока по БД (ее и так меняем).
Программ может быть много, на разных языках, они могут быть установлены на многих компах
Не требует остановок в работе юзеров во многих случаях от смены прог.
2) На декларативном языке: их моно много менять малыми силами.
Да и ваще иногда и его менять не нуно представления.

Так или иначе это имеет важное значение для многих. Потому было бы опрометчиво пренебрегать этим.

Николай1

И еще - зачем менять базу, если это "никак не заметит приложение"? Из любви к искусству?

Это кому зачем. Опять же приложений клиентских может быть много, а меняется тока часть. Есть серверная часть приложений - тока ее надо менять. Да и хоть из любви к искусству: оптимизация схемы. Мы же не дикари, чтобы с пренебрежением к искусству относиться

В целом, считается, зависимость приложений может отрицательно сказываться на качестве и продолжительности ЖЗЦ ИС.

Насчет клиентских и серверных частей. Производительность труда при использовании РСУБД в несколько раз ниже по сравнению с дореляционной объектной технологией (mumps) из-за отсутствия (среди прочего) интегрированной среды. Изменили, например, длину поля в БД, а у переменной (на "клиентской части") забыли. Зачем там вообще типы? Да еще соответсвие вручную поддерживать. Oracle, надо сказать, несколько "современнее", чем MS SQL, в этом плане, там, все-таки, интеграция появилась на определенном этапе "развития"):
26 июн 08, 21:25    [5855096]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
vadiminfo
Разве таблица позволяет применть алгебру?

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

Про алгебру. И Кодд (см. отчет IBM 1969 года) и Дейт (см., среди прочего стр. 539 8-го издания) хотели бы не утрачивать семантику (по сравнению с дореляционной объектной моделью данных) путем выделения связей между сущностями в отдельные "специализированные отношения". Но с алгеброй не срослось.
Я довольно долго искал белее-менее естественное применение для алгебры. Нужна область с явно не связанными объектами. И вот что-то наклевывается. Статистическая алгебра (так как статистические показатели явно не связаны). Я бы даже сказал, неформально выражаясь, что эта алгебра семантическая, так как именно привносит смысл по сравнению с традиционными приемами манипулирования статистическими показателями.
26 июн 08, 21:34    [5855119]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

к стате, а что такое фокспро 2.0 ? язык там нафигационный, SQLем не пахнет ...

Ну, а поможет этой СУБД лэйбла что она реляционная продвинуться на рынке? Если нет, то какая разница?
26 июн 08, 21:36    [5855121]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
2^10
Guest
добавлю за фокспро (я по нему эмсиэсди в 2000 году ещё) - таких много. Этот среди подобных был очень удачный но приоритеты сменились. Не теория относительности, не 12 правил (и не 14, гыгы) а приоритеты бузинеса.
26 июн 08, 21:44    [5855144]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
А ссылку дать?

Можно, например, с помощью Кузнецова:
http://www.citforum.ru/database/articles/codd_1.shtml
26 июн 08, 21:48    [5855152]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
недостатки иерархических

1) с помощью enqueue приложение обращается к владельцу ресурса (OS) за блокировкой
2) с помощью select for update приложение обращается к владельцу ресурса (оракл) за блокировкой.

Или что положено юпитеру то не положено быку?


во первых, там было тьма способов открыть VSAM файлик и один способ ничерта не знал о других способах и только некий Transactional VSAM вроде как победил этот бардак.
далее, обращение за эксклюзивной блокировкой на весь файл это и есть Юпитер и бык, система просто превратится в однопользовательскую где доступ просто сериализован (это то, что я назвал зачатки). если же воротить самопальный менеджер блокировок (и руками воротить Read Commited & Repeatable Read ), то этим можно заниматься бесконечно. откройте ANSI SQL там описаны некоторые из феноменов возникающих при конкурентном доступе. прийдется наворотить десяток видов блокировок их менеджмента, чтоб хотя бы на фоне mSQL не выглядеть сильно ущербным.
Юпитер (оракл) же из коробки дает консистентный набор, читатели не блокируют писателей и прочие прелести IL Snapshot.

2vadiminfo
>Ну, а поможет этой СУБД лэйбла что она реляционная продвинуться на рынке? Если нет, то какая разница?

понятия не имею в контексте разговора о МД, думал вы поясните ....
26 июн 08, 22:22    [5855204]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Ага, а почему ? (ответ: в РСУБД другая МД)

Ответ расширеная РМД. Главнное от РМД обеспечивается? Право на ярлык Реляционная получено.
Поддержка ООП тоже по началу считалась расширением и тока позже появился термин ОРМД.
Кстати, в ИМД есть тока навигация. А если в ИСУБД есть, то это наверное расширение. Счас типа если СУБД не может представить ниче для декларативного доступа, то на рынке ей ловить нечего.

_мод

Когда создавали первые СУБД алгебру не придумали, а когда ее придумали для РМД, на И и С МД ее не распространили за ненадобностью. Хотя и можно.

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


_мод

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

Манипулирование данными имеет отношение и еще какое. А под фразой навигационный доступ и скрывается манипулирование данными для ИМД. Чем хуже извлечение инфы, тем менее пользы от МД.
Зачем БД вообще нужны? Самая выразительная МД - реальный мир, но извлечь инфу сложно. Потому и придумали БД, чтопы получать быстро нужное. Или для чего они нужны? Чтобы занять персонал набором данных?

Как тока Вы у вас появятся таблы как в РСУБД, и Вы будете делать с ними тоже, то Вашу СУБД моно буит переименвать в РСУБД или в ИРСУБД. Но с IMS этого не произошло судя по литре. Она ИСУБД. Значит что-то пока не так как в РСУБД. Видно таблиц не достаточно.
Возможно, таблицы таблицам рознь. Таблицы в РСУБД должны представлять отношение, т.е. это не любые таблицы. Короче, для сранения МД проще идти от конструкций МД а не их представлений в СУБД. Т.е. отношений РМД и типов записей в ИМД.
26 июн 08, 22:31    [5855220]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

понятия не имею в контексте разговора о МД, думал вы поясните ....

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

Но вот появилось понятие универсальный сервер, када типа разные МД поддерживаются в СУБД.
Вот Каша, например, поддерживает и РМД и ООМД и многомерная МД (ушли типа от сетевая или иерахическая) там типа есть. Есть книжка "Постреляционная СУБД Каша".
Но то, что Мод говорит, пока что-то не стыкуется ни с чем, что читал до сих пор.
26 июн 08, 22:52    [5855289]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Но с алгеброй не срослось. Нужна область с явно не связанными объектами.

А чем связи между таблицами могут мешать для применения алгелбры ? При выборке они служат прямым указанием, при изменениях - ограничениями.
27 июн 08, 09:06    [5856120]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
Короче, для сранения МД проще идти от конструкций МД а не их представлений в СУБД.

Проще, но не конструктивно. Поскольку в СУБД реализованы не совсем те МД. Поэтому и приходится сравнивать либо конкретные СУБД либо их классы. Но с классами сложнее: например IMS считается иерархической, на самом деле она сетевая. Реляционный Oracle поддерживает иерахию в чистом виде. Любая сетевая СУБД может использоваться как реляционная.
зы не видел ни одной СУБД с чисто навигиционным доступом, всегда есть какие-то декларации.
27 июн 08, 09:21    [5856180]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
VoDA
Сортировки во вложенных запросах по факту - НЕТ.

Поиск первого-последнего
select * from (select * from t where ..... order by ...) where rownum=1
27 июн 08, 09:50    [5856329]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
_мод
Проще, но не конструктивно. Поскольку в СУБД реализованы не совсем те МД. Поэтому и приходится сравнивать либо конкретные СУБД либо их классы.

Вот если Вы сравниваете классы, то МД и помогает увидель лес в целом из-за деревьев.
27 июн 08, 09:59    [5856380]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
SergSuper
Т.е. убивает человека не пуля, а кусок свинца, летящий со скоростью 300 м/с

Человека убивает пуля, а нее изображение.
27 июн 08, 10:02    [5856396]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
_мод
Но с классами сложнее: например IMS считается иерархической, на самом деле она сетевая. Реляционный Oracle поддерживает иерахию в чистом виде. Любая сетевая СУБД может использоваться как реляционная.
зы не видел ни одной СУБД с чисто навигиционным доступом, всегда есть какие-то декларации.

Раз она считается иерахической и знаем, что означает ИМД, то мы знаем к какому классу она принадлежит и главные свойства этого класса. Если Вы считаете ее сетевой, то просто считаете, что она относится к другому классу. В крайнем случае это трудность классификации. А без МД труно понять что это за классы. И вообще опредилить сами классы. Второе несколько хуже, мне все еще кажется.
27 июн 08, 10:16    [5856468]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Yo.! - опять вы всё о том же...
Ну не может VSAM (метод доступа) выглядеть ущербно на фоне mSQL, oracle, MySQL , и других баз данных - только потому, что это НЕ БАЗА ДАННЫХ!
Сколько же вы будете сравнивать "файловые" операции с базой данных?
Уж начали читать доку - так продолжите, а не пишите про "тьма способов открыть VSAM файлик"
Есть проблемы в конкурентном доступе при использовании VSAM, но так прочитайте хоть, что за проблемы.
27 июн 08, 11:17    [5856855]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить