Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
vadiminfo
MX -- ALEX

А что ж так - 20 лет мучаемся ?


Вам положена большая медаль за приверженность к старинным технологиям. Смотел какую-то передачу про страны, в которые цивилизация не дошла, там пошли еще дальше: мучаются столетиями с устаревшими технологиями, благодаря чему есть что показывать телезрителям в дневное время по выходным.


Извините - но Вы не так поняли текст.
Мучаемся не мы - речь по контексту шла про 15% мучеников в МИРЕ
и что их эти 15 % ну никак не перегнать на реляционные СУБД

Хотя делов то - всего ничего - см выше

А Почетную Грамоту за приверженность реляционным технологиям
Вы тоже вполне заслужили.
30 июл 08, 14:04    [6004619]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
DBjob

Я говорил о локальной разработке. У Оракла есть определенные артефакты связанные с изоляцией транзакций.


Википедия

Артефа́кт (от лат. artefactum — искусственно сделанное) — явление, процесс, предмет, свойство предмета или процесса, появление которого в наблюдаемых условиях по естественным причинам невозможно или маловероятно. Появление артефакта, следовательно, является признаком целенаправленного вмешательства в наблюдаемый процесс, либо наличия неких неучтённых факторов.


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

В Вашем случае же случае все артефакты вызваны,
неучтенными факторами, потому как с точки зрения контроля целостности данных
формального описания поведения МД нет и законов ее поведения тоже нет
во всяком случае их никто не видел, иначе меня бы уже давно Бред или кто либо другой
ткнули бы туда носом.
30 июл 08, 14:28    [6004780]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX
Извините - но Вы не так поняли текст.
Мучаемся не мы - речь по контексту шла про 15% мучеников в МИРЕ
и что их эти 15 % ну никак не перегнать на реляционные СУБД

Хотя делов то - всего ничего - см выше

А Почетную Грамоту за приверженность реляционным технологиям
Вы тоже вполне заслужили.


Ну, теперь я не понял кто все таки мучается. Вы не среди этих 15% (хотя их может быть и меньше)?
Про перегнать тоже теперь не понял. То "ну никак не перегнать на реляционные СУБД", то "Хотя делов то - всего ничего - см выше".

В любом случае я этими мученниками восхищаюсь, но не завидую. От того и считаю достойными медали.

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

Парням же верящим стока лет, что тазы луче, награда положена, по-моему. В этом есть что-то героическое.
30 июл 08, 14:29    [6004786]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Yo.!
Guest
vadiminfo

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

ага, премия Дарвина
30 июл 08, 14:38    [6004856]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
любапыцтвующий
Guest
DBjob
А что Вы подразумеваете под непротиворечивостью?

Удивительно, но на одной странице мы уже увидели два совершенно разных определения непротиворечивости, которые есть смысл внести в протокол (казусов):

1. нормальные формы:
onstat-
Я( за других не скажу)
подразумеваю соответствие представления данных нормальным формам РМД.


2. транзакции:
SergSuper
Допустим если Вы с одного счета какую-то сумму списали, то на другом счете она тут же должна появиться

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

Ну и есть конечно третья интерпретация:

3. логическая:
Состояние считается непротиворечивым, если нет логического противоречия, если его выразить в формальном виде (например, в виде логики предикатов). В частности (и в основном), не нарушаются ограничения целостности.

К этом надо добавить, что только последняя интерпретация является правильной интерпретацией. Но в РМ она свелась к примитиву соответствия ограничениям целостности. Это означает, что в реалиях, выполняются локальные проверки при каждом добавлении или изменении записи, что вполне можно назвать вырожденной формой. В полной же и наиболее интересной форме нахождение противоречий требует полноценного логического вывода, который отсутствует в РМ, ну либо хотя бы каких то более сложных ОЦ.

onstat-
Меня устроит только формализованное описание, такое же, которым дается описание НФ в РМД.

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

onstat-
Я с удовольствием посмотрю на формализованное описание уровней изолированности
транзакций для ОСУБД (как в стандарте SQL) в контексте понятия навигация .

Теоретически, транзакциональность либо есть, либо ее нет, а наличие уровней изолированности это что-то вроде степеней свежести. Другими словами, есть только один уровней транзакции, а все остальные это от лукавого, которые созданы из практических соображений (в основном производительность). Кроме того, транзакции не имею отношения к модели данных, ну или, если хотите, этот механизм является ортогональным к МД.
30 июл 08, 14:38    [6004857]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
onstat-
DBjob

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


Я( за других не скажу)
подразумеваю соответствие представления данных нормальным формам РМД.

И чем более БД нормализована тем более непротиворечива?

onstat-
А Вы что подразумеваете?

Вопрос был Злому, который сказал что доказано что РМД не противоречива. Я хотел узнать о каких противоречиях идет речь и почему другие модели данных не могут быть непротиворечивыми.


onstat-
Какие ограничения на представления данных имеются в ОСУБД?

Зависит от модели данных.


onstat-
DBjob

Вобще то и для ОСУБД существуют алгоритмы обработки конкурентных транзакций. Причем более качественные чем скажем у Оракла.


Я с удовольствием посмотрю на формализованное описание уровней изолированности
транзакций для ОСУБД (как в стандарте SQL) в контексте понятия навигация .

Обычные уровни. От Read Commited до Serializable.

onstat-
В стандарте SQL понятия навигация нет , поэтому можете даже не утруждать себя плагиатом.

Я про навигацию ничего не говорил. А SQL - это конечно наиболее рапространенный запросный язык, но он вполне заслуживает замены на что то более современное и менее громоздкое.
30 июл 08, 14:44    [6004920]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
onstat-
DBjob

Я говорил о локальной разработке. У Оракла есть определенные артефакты связанные с изоляцией транзакций.


Википедия

Артефа́кт (от лат. artefactum — искусственно сделанное) — явление, процесс, предмет, свойство предмета или процесса, появление которого в наблюдаемых условиях по естественным причинам невозможно или маловероятно. Появление артефакта, следовательно, является признаком целенаправленного вмешательства в наблюдаемый процесс, либо наличия неких неучтённых факторов.


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

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

Эти артефакты называются иногда аномалиями. У Оракла это "Write Skew" и "Read Only Transaction" аномалии. Когда поведение Оракла в определенных случаях не соответсвует стандарту SQL в части изоляции транзакций.

Не знаю что Вы имеете в виду под поведением МД, но транзакции и триггера по моему мнению от МД лежат немного сбоку. Это дополнительный сервис надстроенный над РМД предлагаемый пользователям в современных СУБД.
30 июл 08, 14:57    [6005024]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

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

Страшно сказать, что и Ключи не нужны :-).
30 июл 08, 15:04    [6005075]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
любапыцтвующий
DBjob
А что Вы подразумеваете под непротиворечивостью?

Удивительно, но на одной странице мы уже увидели два совершенно разных определения непротиворечивости, которые есть смысл внести в протокол (казусов):

1. нормальные формы:
onstat-
Я( за других не скажу)
подразумеваю соответствие представления данных нормальным формам РМД.


2. транзакции:
SergSuper
Допустим если Вы с одного счета какую-то сумму списали, то на другом счете она тут же должна появиться

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


Полностью согласен.


любапыцтвующий


Ну и есть конечно третья интерпретация:

3. логическая:
Состояние считается непротиворечивым, если нет логического противоречия, если его выразить в формальном виде (например, в виде логики предикатов). В частности (и в основном), не нарушаются ограничения целостности.

К этом надо добавить, что только последняя интерпретация является правильной интерпретацией. Но в РМ она свелась к примитиву соответствия ограничениям целостности. Это означает, что в реалиях, выполняются локальные проверки при каждом добавлении или изменении записи, что вполне можно назвать вырожденной формой. В полной же и наиболее интересной форме нахождение противоречий требует полноценного логического вывода, который отсутствует в РМ, ну либо хотя бы каких то более сложных ОЦ.


Я понимаю Вашу мысль.
Вы предлагаете строить новую модель под каждое новое приложение?
Зачем тогда такая БД нужна, можно писать на С.С++.С# и даже на асемблере.

Если не предлагаете, посмотрите еще раз на гипотезы, которые я выдвигал об асоциативном восприятии,
Исходя из понятия
автор

ассоциативное восприятие - минимальное количество данных необходимое для востановления семантеки данных

Википедия

Сема?нтика (фр. semantique от греч. ?????????? - обозначающий) также семасиология - наука о понимании определённых знаков, последовательностей символов и других условных обозначений; раздел семиотики.

* Лингвистическая семантика
* Семантика в программировании
* Онтопсихология

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


Вы никогда не получите МД, которая сможет отражать все так как вы хотите без
введения ограничений на уровне модели, Вам нужно вводить законы по которым будет проводится оценка. А законы это есть прямые или косвенные ограничения.

Это компромис, если МД не планирует иметь инструментов и законов контроля целостности, то так и скажите, МД этим не занимается, только при этом желательно точно сказать на кого(что) возлагается эта функция.

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

Для меня эта недомодель пока еще очень противоречива.

любапыцтвующий

onstat-
Меня устроит только формализованное описание, такое же, которым дается описание НФ в РМД.

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


Ключево фразой есть " почему не сделать модель, "
За декларировать и сделать две большие разницы,
Я пока не вижу даже толковой декларации, тут реализацией( деланьем) еще даже
и не пахнет.

ИМХО
нет смысла что то делать не имея точной цели, и путей ее достижения.
Если целью есть модель, то декларация , фундаментальное описание базовых принципов,
есть путем.
Фундаментального описания ( как описание НФ в РМД) я еще не видел .
\ИМХО

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

Другими словами данные нужно ложить на хранение в БД в соответствии с правилами
которые описывает проект, а проект основан на РМД.

Это тоже самое что строить дом из чего попало, или строить дом из материалов соответствующих ГОСТам.


любапыцтвующий

onstat-
Я с удовольствием посмотрю на формализованное описание уровней изолированности
транзакций для ОСУБД (как в стандарте SQL) в контексте понятия навигация .

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


Согласен, в уровни изолированности еще рано лезть пока не определены другие фундаментальные понятия модели.
30 июл 08, 19:28    [6006813]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
vadiminfo
MX -- ALEX
Извините - но Вы не так поняли текст.
Мучаемся не мы - речь по контексту шла про 15% мучеников в МИРЕ
и что их эти 15 % ну никак не перегнать на реляционные СУБД

Хотя делов то - всего ничего - см выше

А Почетную Грамоту за приверженность реляционным технологиям
Вы тоже вполне заслужили.


Ну, теперь я не понял кто все таки мучается. Вы не среди этих 15% (хотя их может быть и меньше)?
Про перегнать тоже теперь не понял. То "ну никак не перегнать на реляционные СУБД", то "Хотя делов то - всего ничего - см выше".

В любом случае я этими мученниками восхищаюсь, но не завидую. От того и считаю достойными медали.

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

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


На одном подопытном заводе-холдинге все сделано без реляционной херни
Крутится вполне комфортно без проблем лет 15

Понадобилось подключитьсчя к банку
У банка своя прога других низззя
Поставили банкиры - валится примерно раз в месяц
каждый раз по другой причине
РРеляционный Лекксусс
Заколебал

не - мы лучше на тракторе
30 июл 08, 23:53    [6007379]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Я надеюсь меня поддержат с таким обращением:

В связи с тем что в теме (как ни странно) пошли довольно взвешенные высказывания, хотел бы попросить (или предупредить) г-на ЧАЛ (или Бред-а) не засирать топик. Пожалуйста не более одного поста и разумного размера. Остальное будет стёрто безотносительно содержания.
31 июл 08, 00:00    [6007391]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
MX -- ALEX

А что ж так - 20 лет мучаемся ?

нет чтобы взять и быстренько переписать
благо, с Ваших слов :

<<Реляционная модель не оперирует объектами и связями между ними. Ставьте и формализуйте задачу на естественном (русском, английском, французском или арабском - выбор за вами) языке, мы вам предложим реляционное ее решение. Причем я берусь гарантировать что решение любой нетривиальной задачи по автоматизации предприятия сделанное на базе Oracle + ERP софт + Microstrategy будет разработано быстрее, в эксплуатации дешевле, поддерживается проще, масштабируется на два порядке лучше чем сделанный на коленке самопал поверх каши.>>


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

Если же автоматизация уже была сделана 30 лет назад, то даже при условии что она была сделана убого и на технологиях тех времен поддерживать то что уже сделано может оказаться дешевле и практичнее. И вся любовь. Поэтому в крупнейшем американском банке до сих пор поддерживают систему изначально написанную во времена президента Линдона Джонсона. Ее переписывать гораздо дороже чем поддерживать. Системы которые пишутся сегодня естественно не пишутся на технологиях тридцатилетней давности - умалишенных нет.
31 июл 08, 07:06    [6007698]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
_мод
Зл0й
Одно из основных преимуществ реляционной СУБД в том что для нее можно (хотя это и непросто) написать оптимизатор запросов.

оптимизатор запросов можно написать для любой СУБД - если в нем есть необходимость

А откуда у вас такая уверенность? Если как писать оптимизатор реляционной СУБД мне хотя бы в общих чертах понятно как это делать. Алгоритмы более-менее известны, оракла и DB2 на опубликованных в статьях и книгах алгоритмах сделать скорее всего не получится, но что-то типа MySQL вполне можно. А где статьи и теория на тему как писать оптимизатор для нереляционной СУБД? Могу нарыть по IDMS, но это 70е и толком из этой затеи ничего не вышло. Из объектно-ориентрированных СУБД 90х тоже вышел мерзкий пшик. Мне лично далеко не очевидно что эта задача разрешима, пока что вижу кучу неудачных проектов на эту тему, и не одного удачного (завершившегося коммерческим продуктом, долей рынка и мешком денег).


_мод

Зл0й

Для СУБД основанных на сетевой модели реализовать оптимизатор запросов и язык высокого уровня работающие с приемлемой производительностью так и не удалось.

В ССУБД оптимизатор запросов вырождается и становится тривиальным. ЯВУ вообще не причем.

Ну то есть в отличие от реляционной модели где есть разделение на физический уровень и логический в CODASYL его нетути. В реляционной СУБД оракл я одну и ту же "логическую" таблицу могу физически реализовать в виде кучи, B* дерева или хэш-таблицы. Или поменять физическую реализацию не переписывая приложения. Потому что приложение с СУБД общается на языке высокого уровня. Вы нам предлагаете вернуться обратно в 70е годы прошлого века, на уровень ниже? То есть вместо языка высокого уровня приложение общается с СУБД на языке низкого уровня и в рамках физической модели (циклы, указатели итп). Тогда действительно оптимизатор не нужен. Точно так же как не нужен компилятор С++ если приложение писать на ассемблере. На эти грабли мы уже наступали один раз, в былые времена и приложения писались на ассемблере IBM/370 и с СУБД разговаривали на языке более низкого уровня чем SQL и модель данных была сетевая. Все было в ажуре? Зачем тогда 30 лет весь мир фигней страдает?

_мод

Зл0й

Поэтому в нереляционных СУБД нет разделения модели данных на физическую и логическую

Ну да ? (в IMS данные могут храниться на МЛ, и где это определено в МД ?)

Речь не о том в каком dataset данные лежат, а о том можете ли вы поменять физическую структуру хранения данных (например с хэш-таблицы на B*tree). В IMS вы не можете этого сделать по определению, потому что модель данных иерархическая и привет. В IDMS и CODASYL у вас хоть какой-то выбор есть, правда при этом приложение придется переписывать.

_мод

Зл0й

и "план исполнения запроса" который в РСУБД генерирует оптимизатор в нереляционных СУБД пишет программист, "ручками", часто с помощью циклов.

В некоторых РСУБД то же самое - какое это имеет отношение к МД.

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

А теперь представьте что у вас вместо ограничений - бардак. Нет аксиоматики, невозможно даже ввести понятие метрики. Можно тут какую-нибудь теорию построить? Нет. И главное - незачем. Несмотря на ограничения которые накладывает реляционная модель, как показывает практика реальные системы на ее основе пишутся быстрее и работают качественнее чем нереляционные. Поэтому нереляционными и не занимется никто. Это как паровая машина ее заменят на двигатель внутреннего сгорания когда сломается. Но разработки новых типов паровых машин с появлением ДВС умерли навсегда.
31 июл 08, 07:38    [6007727]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
DBjob
Зл0й
Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

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

То что при грамотно спроектированной реляционной СУБД (нормализация, ограничения целостности) как бы я не задавал вопрос ( я могу 125 различных вариантов SQL написать задающих один и тот же вопрос) я всегда гарантировано получу один и тот же ответ.


DBjob

Зл0й
Последний "гвоздь" в гроб нереляционных СУБД заколотили разработки работы в области поддержки конкурентных транзакций. Для реляционных СУБД существуют алгоритмы обработки конкурентных транзакций (например читатели-писатели) корректность которых математически доказуема. Желающих убедиться отсылаю к классической книге Джима Грея.

Нереляционных СУБД в лучшем случае поддерживают весьма ущербную по сравнению с реляционными обработку транзакций. Поэтому ее обычно выносят в отдельный продукт такой как например CICS. Поскольку этот продукт не является СУБД, то о гранулярности блокировки типа записи или страницы можете забыть. При всех прочих равных масштабируемость реляционной системы всегда выше чем это безобразие. Оно используется до сих пор только потому, что переписывать системы разработанные 30 лет назад неоправданно дорого. Дешевле их поддерживать.

Вобще то и для ОСУБД существуют алгоритмы обработки конкурентных транзакций. Причем более качественные чем скажем у Оракла.

Да ну? Позвольте полюбопытствовать а кто их разработал и когда, в какой СУБД они были реализованы и какое количество конкурентных транзакций эта система может обрабатывать, скажем речь про нечто вроде далеко небезупречного TPC теста.

Мы транзакции поддерживаем на высоком уровне или на низком? То есть у нас приложение с СУБД общается на языке высокого уровня (типа например SQL) или на более низком? Блокировки вручную можно было ставить и на коболе 30 лет назад и на MUMPS. Только вот геморройно это, потому что их нужно ставить и снимать не абы как, а по определенным правилам (см. книгу Джима Грея). Отлаживать такие системы и отлавливать там deadlocks и race conditions - это просто "тихий ужас". Производительность труда программиста при таком подходе мизерная. Поэтому как только появилась возможность простенько сделать

set transaction isolation ...

savepoint 1

select ...

update ...

if (...) rollback to savepoint 1

select ...

update ...

delete ...

commit

то простой программистский народ за нее схватился руками, ногами и зубами. Потому что в противном случае, если писать это все "вручную" и ставить/снимать каждую блокировку "ручками" то нужно раз в 100 больше времени и сил. "А зачем нам кузнец, нам кузнец не нужен" (С).
31 июл 08, 07:52    [6007741]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
Зл0й

Мы транзакции поддерживаем на высоком уровне или на низком? То есть у нас приложение с СУБД общается на языке высокого уровня (типа например SQL) или на более низком? Блокировки вручную можно было ставить и на коболе 30 лет назад и на MUMPS. Только вот геморройно это, потому что их нужно ставить и снимать не абы как, а по определенным правилам (см. книгу Джима Грея). Отлаживать такие системы и отлавливать там deadlocks и race conditions - это просто "тихий ужас". Производительность труда программиста при таком подходе мизерная. Поэтому как только появилась возможность простенько сделать

set transaction isolation ...

savepoint 1

select ...

update ...

if (...) rollback to savepoint 1

select ...

update ...

delete ...

commit

то простой программистский народ за нее схватился руками, ногами и зубами. Потому что в противном случае, если писать это все "вручную" и ставить/снимать каждую блокировку "ручками" то нужно раз в 100 больше времени и сил. "А зачем нам кузнец, нам кузнец не нужен" (С).


Вы не поверите
но на нереляционной в принцине CACHE (на стандарте MUMPS)
разработанном Американской фирмой и используемой сейчас
чаще всего именно в США
(где сумасшедших нет по определению :)

блокировки ставятся именно так почти дословно
31 июл 08, 08:57    [6007880]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Зл0й

Чтобы избежать дальнейшего взаимного непонимания изложу (частично) свою кочку зрения:
РМД это частный случай сетевой МД. То что сделано для РМД (SQL, оптимизация, изоляция и т.тд), м.б. сделано и для ССД. Такие попытки (не очень удачные) уже есть (netsted tables Oracle). Посему надо двигаться не назад, а вперед - путь указан. Правда чисто технически это не так просто. "Новое - хорошо забытое старое".
31 июл 08, 09:24    [6007961]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

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

Чтобы избежать дальнейшего взаимного непонимания изложу (частично) свою кочку зрения:
РМД это частный случай сетевой МД. То что сделано для РМД (SQL, оптимизация, изоляция и т.тд), м.б. сделано и для ССД.


Целые числа - частный случай вещественных, поэтому ВСЕ что можно сделать для целых (например пересчитать), можно сделать и для вещественных тоже. ага

P.S. Про отсутсвие в Америке сумасшедших "по определению" тоже проперло
31 июл 08, 09:34    [6008025]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
_мод
Зл0й
Одно из основных преимуществ реляционной СУБД в том что для нее можно (хотя это и непросто) написать оптимизатор запросов.

оптимизатор запросов можно написать для любой СУБД - если в нем есть необходимость

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

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


Зл0й

_мод

Зл0й

Поэтому в нереляционных СУБД нет разделения модели данных на физическую и логическую

Ну да ? (в IMS данные могут храниться на МЛ, и где это определено в МД ?)

Речь не о том в каком dataset данные лежат, а о том можете ли вы поменять физическую структуру хранения данных (например с хэш-таблицы на B*tree). В IMS вы не можете этого сделать по определению, потому что модель данных иерархическая и привет. В IDMS и CODASYL у вас хоть какой-то выбор есть, правда при этом приложение придется переписывать.

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



Зл0й

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

Но электромобили то разрабатывают. :-) Пока они корявые и хилые как нынешние ОСУБД, но может оказаться что со временем ОСУБД вытеснят РСУБД.
31 июл 08, 09:48    [6008081]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Gluk (Kazan)
(например пересчитать)

Пробовали ? А по существу ?
31 июл 08, 09:49    [6008085]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
_мод
Gluk (Kazan)
(например пересчитать)

Пробовали ? А по существу ?


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

Я не прав ?

P.S. Рациональные пробовал (но их НЕСКОЛЬКО меньше чем иррациональных, вот в чем фокус)
31 июл 08, 10:02    [6008167]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
DBjob
Зл0й
Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

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

То что при грамотно спроектированной реляционной СУБД (нормализация, ограничения целостности) как бы я не задавал вопрос ( я могу 125 различных вариантов SQL написать задающих один и тот же вопрос) я всегда гарантировано получу один и тот же ответ.

Так и для ОСУБД это возможно.


Зл0й
DBjob

Зл0й
Последний "гвоздь" в гроб нереляционных СУБД заколотили разработки работы в области поддержки конкурентных транзакций. Для реляционных СУБД существуют алгоритмы обработки конкурентных транзакций (например читатели-писатели) корректность которых математически доказуема. Желающих убедиться отсылаю к классической книге Джима Грея.

Нереляционных СУБД в лучшем случае поддерживают весьма ущербную по сравнению с реляционными обработку транзакций. Поэтому ее обычно выносят в отдельный продукт такой как например CICS. Поскольку этот продукт не является СУБД, то о гранулярности блокировки типа записи или страницы можете забыть. При всех прочих равных масштабируемость реляционной системы всегда выше чем это безобразие. Оно используется до сих пор только потому, что переписывать системы разработанные 30 лет назад неоправданно дорого. Дешевле их поддерживать.

Вобще то и для ОСУБД существуют алгоритмы обработки конкурентных транзакций. Причем более качественные чем скажем у Оракла.

Да ну? Позвольте полюбопытствовать а кто их разработал и когда, в какой СУБД они были реализованы и какое количество конкурентных транзакций эта система может обрабатывать, скажем речь про нечто вроде далеко небезупречного TPC теста.

Я говорю о разработке одной российской команды. Количество транзакций физически не ограничено, а насколько алгоритмы эффективны покажет конечно TPC тест.


Зл0й
Мы транзакции поддерживаем на высоком уровне или на низком? То есть у нас приложение с СУБД общается на языке высокого уровня (типа например SQL) или на более низком?

На языке высокого уровня.

Зл0й
Блокировки вручную можно было ставить и на коболе 30 лет назад и на MUMPS. Только вот геморройно это, потому что их нужно ставить и снимать не абы как, а по определенным правилам (см. книгу Джима Грея). Отлаживать такие системы и отлавливать там deadlocks и race conditions - это просто "тихий ужас". Производительность труда программиста при таком подходе мизерная. Поэтому как только появилась возможность простенько сделать

set transaction isolation ...

savepoint 1

select ...

update ...

if (...) rollback to savepoint 1

select ...

update ...

delete ...

commit

то простой программистский народ за нее схватился руками, ногами и зубами. Потому что в противном случае, если писать это все "вручную" и ставить/снимать каждую блокировку "ручками" то нужно раз в 100 больше времени и сил. "А зачем нам кузнец, нам кузнец не нужен" (С).

В системе о которой я говорю, блокировки появляются только на уровне Serializable, и то их вероятность существенно меньше чем у реляционных РСУБД. А главное что сервер сам занимается сериализацией транзакций, а не отфутболивает одну из конфликтующих транзакций обратно приложению. То есть в большинстве случаев программисту не нужно даже думать о всяких savepoints.
31 июл 08, 10:06    [6008179]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
Зл0й
Одно из основных преимуществ реляционной СУБД в том что для нее можно (хотя это и непросто) написать оптимизатор запросов.

оптимизатор запросов можно написать для любой СУБД - если в нем есть необходимость


Адептам модели есть еще один повод подумать IMHO

Качество навигации, семантика, уровень ассоциативного восприятия есть в принципе одно и тоже.

Качество навигации ( семантика) описывается диф функцией второго или
третьего порядка ( точнее сказать не могу, это же ИМХО ),
Когда у вас будут готовы математические выкладки по этому поводу,
можно будет говорить о том что развитие вашей модели двинулась с мертвой точки.

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

Только тогда посмотрев на мат. модель можно будет оценить ее большую перспективность
относительно РМД.

А пока увы.
31 июл 08, 10:16    [6008244]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Gluk (Kazan)
Я не прав ?

Торетически, да :) Но применительно к нашему вопросу: РМД отличается от ССД только отсутствием связей, которые в ССД накладывают ограничения, аналогичные PK-FK в РМД. Поскольку для РМД с PK-FK все сделано, то то же самое можно сделать для ССД.
31 июл 08, 11:04    [6008676]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Только тогда посмотрев на мат. модель можно будет оценить ее большую перспективность относительно РМД.

ССД и РМД - это по сути одна и та же МД.
31 июл 08, 11:07    [6008713]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
_мод
Gluk (Kazan)
Я не прав ?

РМД отличается от ССД только отсутствием связей, которые в ССД накладывают ограничения, аналогичные PK-FK в РМД.


Теоретически из этого следует, что как раз таки Ваша ССД является частным случаем РМД
Плоха та практика, что не согласуется с теорией.

Может быть все таки НЕ ТОЛЬКО этим они отличаются ???
31 июл 08, 11:10    [6008739]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить