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

Откуда: SPb
Сообщений: 5488
Bald
fanat_FOXa

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

Ну-ну. Посмотрим как Вы будете искать тэг с опеределённым аттрибутом и с определёнными вложенными тэгами

А РСУБД работают не с записями, а с данными, поэтому у них скорость выше :)

fanat_FOXa

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

и я про это

neznajka

А что конкретно Вы имели в виду под выражением "на уровень выше"?

Не с файлами работать, а с данными. Т.е. использовать какую-нибудь СУБД. Хотя конечно не для всех задачах это лучше, но для большинства так
10 июн 05, 17:27    [1614549]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
ilias1979
Member

Откуда: Мытищи
Сообщений: 386
XML не стоит использовать для хранения данных вообще, не говоря уже о базе на XML.
Это не более чем способ передачи данных.
По вопросу скорости выборки из такой "базы", я думаю многим из пишущих здесь сторонников XML, будет очень полезно почитать статью Джоэла Сполски "Назад, к основам"
[url=http://]http://russian.joelonsoftware.com/Articles/BacktoBasics.html[/url]
10 июн 05, 17:37    [1614600]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
ilias1979
Member

Откуда: Мытищи
Сообщений: 386
НАЗАД К ОСНОВАМ
10 июн 05, 17:39    [1614609]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
Андрей Леонидович
Guest
РСУБД должны были бы работать с данными, "организованными" в отношения. Но из этого так ничего и не получилось. И даже отказавшись от отношений, скорость "Р"СУБД (а уже не РСУБД) была доведена до приемлемой для приложений в результате титанических 25-летних усилий...

XML не "конечно не стоит", а редко когда стоит, на мой взгляд, использовать для "хранения" данных (речь ведь идет о "логическом" "хранении"). Так же как и "Р"СУБД...

А, прочитав статью Джоэла Сполски, полезно было бы получить представление о языках, специально ориентированных на обработку "логических" строк...
10 июн 05, 20:24    [1615040]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
fanat_FOXa
Member

Откуда:
Сообщений: 110
To Bald:
Пожалуйста приведите примеры (хотябы общие, или ссылки на таковые), где упоминается выигрыш в скорости поиска по "физическим ссылкам на запись-родителя" по сравнению с индексированным поиском в двумерных таблицах, связанных отношениями. Просто обратных утверждений в этом топике хватает, хотелось бы объективности ради ознакомиться и примерами упомянутого выигрыша в поиске по XML-базе.
10 июн 05, 23:15    [1615228]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

Просто обратных утверждений в этом топике хватает, хотелось бы объективности ради ознакомиться и примерами упомянутого выигрыша в поиске по XML-базе.

Вообще-то там речь шла о выигрыше иерархической базы, а не XML-базы.
Две большие разницы. Иерархические это те, что господствали в дореляционную эпоху (наряду с сетевыми). Известным примером иерархической СУБД является IMS фирмы IBM. И до 1986 года они действительно в скорости значительно выигрывали. Вплоть до того, что РСУБД не претендовали поддерживать OLTP системы до 1986 года. (В 1986 Сибэйс впервые выпустил OLTP РСУБД). Однако, с тех пор все изменилось. Но и в настоящее время одним из направлений развития РСУБД является совершенствование производительности.
Что касается XML-базы, то это как раз что-то новое, типа постреляционное.
Но пока о ее выигрыше в скорости, вроде, никто не говорил. Мож я пропустил что? Более того, возможно, она несколько для других задач, чем "плоские" БД.
11 июн 05, 00:05    [1615264]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
c127
Guest
vadiminfo

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

Знать бы что такое ООСУБД. Но это мы уже обсуждали.

>Но все еще думаю, что XML не сводится к иерархическим.

ХМЛ конечно же не сводится к иерархическим БД, это язык, но структуры которые им определяются естественным образом иерархические. А иерархические структуры слишком узкий класс в смысле приложений. Для остальных нужно извращаться, т.е. усложнять описание, т.е. явный проигрыш.

>Подкину Вам еще ссылку на первоисточник :"Третий закон диалектики - Отрицание отрицания" Иерархические могут через отрицание появиться в новом качестве. Мы не можем это игнорировать.

Не знаком с диалектикой, как и с ООБД, я больше по математике.

>А в Оракле она до сих пор.

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

>Таблицу поменять - другая БД. Так как она входит в структуру, а структура наиболее статичная часть системы в силу своего пределения. А теги добавить - все таже.

Не нужно менять таблицы. Посмотрите ЛДАП в исполнении М$ на МС СКЛ сервере, там 6 или 7 таблиц, реализована фактически иерархическая БД, ничего не меняется. Впихнуть туда ХМЛ ничего не стоит.


2 SergSuper

>Это означает что например эту таблицу можно вполне напечатать на плоском листе.

А можно записать на ленте, или сложить N-мерный (по числу полей) куб. Становится ли она от этого одномерной или N-мерной? Другое дело что таблицу иногда УДОБНО записывать на листе бумаги, но это ничего не значит.
11 июн 05, 03:48    [1615343]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
fanat_FOXa
Member

Откуда:
Сообщений: 110
To vadiminfo
Спасибо за обстоятельное пояснение.
vadiminfo
Вообще-то там речь шла о выигрыше иерархической базы, а не XML-базы

С того расстояния на котором я "нахожусь" от XML-баз и от иерархических баз они все "сливаются" в одну точку :)
vadiminfo
Но пока о ее выигрыше в скорости, вроде, никто не говорил. Мож я пропустил что?

Или я неправильно понял (Конечно, если считать XML-базы и иерархические "близкими" понятиями.):
Bald
А в иерархические базы работают не с таблицами, а с записями.
Запись-потомок содержит физическую ссылку на запись-родителя.
Поэтому поиск намного быстрее, чем в РСУБД.
11 июн 05, 17:50    [1615737]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
fanat_FOXa
Member

Откуда:
Сообщений: 110
To c127:
c127
...таблицу иногда УДОБНО записывать на листе бумаги

и воспринимать неискушенному юзеру тоже так удобнее, а вот
c127
но это ничего не значит

попробуйте объснить это Excel-фанатам на: https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=186195&pg=-1
11 июн 05, 17:56    [1615741]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
fanat_FOXa
Member

Откуда:
Сообщений: 110
To ilias1979:
Большое спасибо за ссылку на статью "Назад к основам".
Теперь все стало на свои места. Вопрос исчерпан.
12 июн 05, 00:01    [1615940]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

Знать бы что такое ООСУБД. Но это мы уже обсуждали.

К какому типу СУБД Вы отеносите, к примеру, Версантовские продкты?

c127

ХМЛ конечно же не сводится к иерархическим БД, это язык, но структуры которые им определяются естественным образом иерархические. А иерархические структуры слишком узкий класс в смысле приложений. Для остальных нужно извращаться, т.е. усложнять описание, т.е. явный проигрыш.

В чем-то проигрыш у всех есть.
Вопрос в том нет ли областей, в которых выигрыш проявляется? Пусть хоть и узкий класс, как Вы говорите. Но дело не в иерархическом.
Иерархическое можно найти и в РМД. Например, унарная связь. Часто употребляют термины предок потомок. В Оракле есть иерархические запросы. Этого не достаточно. Там есть еще кое-что. Я вот Вам намекал - полуструктурированная модель. Нет у такой модели заранее фиксированной схемы. (У иерархических БД - IMS есть). Это бОльшая гибкость.

c127

Не знаком с диалектикой, как и с ООБД, я больше по математике.

А между тем, кое-что в математике сделали именно диалектики - Декарт, Рассел.

c127

Не нужно менять таблицы. Посмотрите ЛДАП в исполнении М$ на МС СКЛ сервере, там 6 или 7 таблиц, реализована фактически иерархическая БД, ничего не меняется. Впихнуть туда ХМЛ ничего не стоит.

Нужно менять схему иногда. Вот в чем траблы. Я не про маппинг или отображение говорил. В ОЛАПе тоже могут использоваться схема звезда или снежинка. Из реляционных табл. Тока это уже не реляционная модель.
Вы обратиет внимание именно на термин полуструктурированная. Вот Вам из литры:
В отличии от других моделей (в этом топике обозначенными под именем "плоские"), данные в "полуструктурированных" модели самодостаточны: схема представления содержится в них самих. Во всех других моделях данные подчиняются фиксированной схеме, описываемой отдельно и загодя, и функции каждого элемента данных неявно регламентируются схемой как таковой.
Это литра по базам данных вообще, и большая часть посвящена реляционным. Т.е. это не ХМЛ - кая книжка.
У сильнотипизированных моделей есть свои преимущества и недостатки, у слаботипизированных свои.


fanat_FOXa

С того расстояния на котором я "нахожусь" от XML-баз и от иерархических баз они все "сливаются" в одну точку :)


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

fanat_FOXa

Или я неправильно понял (Конечно, если считать XML-базы и иерархические "близкими" понятиями.):

Да, наверное, Вы не обратили внимание, на упоминаемые у Bald слова про физические ссылки. Это именно к иерархическим относится, ну и к ООСУБД.
Но врядли к XML. Он чисто логическая. В ней мало физичекого, я думаю.
А Вы говорите - одна точка. Пропасть там. Помяните мое слово.
12 июн 05, 00:41    [1615958]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
c127
vadiminfo
2 SergSuper

>Это означает что например эту таблицу можно вполне напечатать на плоском листе.

А можно записать на ленте, или сложить N-мерный (по числу полей) куб. Становится ли она от этого одномерной или N-мерной? Другое дело что таблицу иногда УДОБНО записывать на листе бумаги, но это ничего не значит.


Поскольку это отличительная особенность(на ленту то что угодно можно записать), присущая всем таблицам (N-мерный куб для таблицы с одними строковыми полями я себе плохо представля), то на мой взгляд всё-таки чего-то означает
12 июн 05, 00:57    [1615964]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
c127
Guest
fanat_FOXa
попробуйте объснить это Excel-фанатам на: https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=186195&pg=-1


Психические патологии не моя специальность, пусть обращаются к специалистам.

vadiminfo

К какому типу СУБД Вы отеносите, к примеру, Версантовские продкты?


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

vadiminfo

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


Так в том же и дело, что прикладные задачи как раз очень редко укладываюстя в иерархическую схему. И что еще хуже, те, которые вроде сначала укладываются, при расширении, которое всегда рано или поздно происходит, тоже уходят из этой области. А БД поменять это та еще проблема, Вы же знаете.

vadiminfo

Там есть еще кое-что. Я вот Вам намекал - полуструктурированная модель. Нет у такой модели заранее фиксированной схемы. (У иерархических БД - IMS есть). Это бОльшая гибкость.


Посмотрите ЛДАП, там это все есть и структура БД не меняется. Но можно не смотреть, принцип по-моему очевиден.

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

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

vadiminfo

А между тем, кое-что в математике сделали именно диалектики - Декарт, Рассел.


Это для Вас они диалектики, а для меня они математики. :) Они же это кое-что сделали в МАТЕМАТИКЕ. Хотя они скорее философы, а не диалектитки, но это опять же слова.

vadiminfo

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


Метаданные тоже можно записать в реляционной схеме. Весь ХМЛ, без исключения, вместе со всеми "данными о данных", причем при изменении ХМЛ схемы структуру таблиц менять не нужно. Чем не полуструктурированные данные?



SergSuper

Поскольку это отличительная особенность(на ленту то что угодно можно записать), присущая всем таблицам (N-мерный куб для таблицы с одними строковыми полями я себе плохо представля), то на мой взгляд всё-таки чего-то означает


Например так. В реальных СУБД длина строки конечна (в МССКЛ это 8К, у оракла 2**32 по-моему, но все равно конечна), всякая строка это натуральное число. Вот Вам и куб, причем даже не с непрерывной стороной, а с дискретной.

Я хотел сказать что способов представления реляционной таблицы много, запись в виде таблицы на листе бумаги просто один из них, далеко не самый точный, куб например гораздо ближе к первоначальному определению отношения.
12 июн 05, 02:26    [1616002]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
fanat_FOXa
Member

Откуда:
Сообщений: 110
Судя по выкладкам, сразу чувствуется - спецы столкнулись. Очень далеко ушедшие от реального уровня юзеров. Так и должно быть. Только "корни" забывать не следует :)
Мне вот недавно довелось объяснять структуру многотабличной кадровой БД обыкновенному кадровику. Так он все прекрасно понял после сравнения кажной главной записи с простынью, на которой упорядочено нашиты "многосекционные кармашки", куда вставляются дополнительные данные в необходимом для данной записи количестве.
:)
12 июн 05, 11:39    [1616066]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

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

Ну, при таком подходе многие СУБД, в том числе и реляционные, окажутся вообще не СУБД. Например, у Аксцесса нет триггеров.

c127

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

Это вопрос сложных исследований, времени. А пока, мне кажется, лучше всех их посчитать, до момента их окончательной отмены или снятия с производства. Тем более, что рациональные их зерна пытаются использовать основные производители. ХМЛ, ООП втюхивают и в Оракл и в Скуль, к примеру.

c127

Посмотрите ЛДАП, там это все есть и структура БД не меняется. Но можно не смотреть, принцип по-моему очевиден.

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

c127

Для меня все что можно записать в реляционной схеме - реляционно.

Но не всегда рел модель данных. А именно модель фундамент БД. Без нее понимать что в этой БД ломновато будет.

c127

Это для Вас они диалектики, а для меня они математики. :) Они же это кое-что сделали в МАТЕМАТИКЕ. Хотя они скорее философы, а не диалектитки, но это опять же слова.


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


c127

Метаданные тоже можно записать в реляционной схеме. Весь ХМЛ, без исключения, вместе со всеми "данными о данных", причем при изменении ХМЛ схемы структуру таблиц менять не нужно. Чем не полуструктурированные данные?

Если полуструктурированные, тока благодаря тому что там в такой форме представлен ХМЛ, а РМД. Вы вот пример про ленту приводили, что на нее можно таблу записать. Но от этого лента не станет таблой. Так и здесь.

Кстати одно из достоинств ХМЛ, что существуют стандартизованные методы его отображения во многие форматы в достаточны выразительном виде. Хотя это напрямую к вопросу МД может и не относится, но говорит о том, что на него сделали ставку в инфотехнолгиях. SQL, например, не нравится Дейту, но из-за этого он теперь уже не сойдет в небытие.
12 июн 05, 13:11    [1616119]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

Очень далеко ушедшие от реального уровня юзеров.

Имел и имею удовольствие с ними общаться много и часто. Причем с разными типами. Говорить на их языке. У них у каждого свой. С учетом того, что из них тока 15% адекватные, как здесь кто-то сказал. Правда они на это всегда спрашивают: "А скока среди вас (проггеров) адекватных?" Но я таких цифр пока не нашел.)
12 июн 05, 13:19    [1616127]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
c127
Guest
vadiminfo

Ну, при таком подходе многие СУБД, в том числе и реляционные, окажутся вообще не СУБД. Например, у Аксцесса нет триггеров.


А где я говорил про триггеры? Есть определение СУБД, не бязательно реляционной, данное Коддом по-меому, оно тут многократно цитировалось.Там гаворится что СУБД должна поддерживать целостность данных и еще много чего. Версант на сервере целостность не поддерживает. Следовательно сервер без клиента не СУБД. Можно к серверу прилепить клиент и это все попытаться назвать сервером, как это делал Alexey Rovdo, но тогда нарушается другой пункт этого определения, что доступ к данным осуществляется токлько через сервер. Вы же участвовали в этой дискуссии и по-моему доказывали что версант не СУБД.

vadiminfo

Это вопрос сложных исследований, времени. А пока, мне кажется, лучше всех их посчитать, до момента их окончательной отмены или снятия с производства. Тем более, что рациональные их зерна пытаются использовать основные производители. ХМЛ, ООП втюхивают и в Оракл и в Скуль, к примеру.


Какие исследования, уже обожглись один раз, на иерархической модели, зачем еще раз наступать на те же грабли. Бедная модель, почти ничего туда хорошо не ложится. Техника стала лучше с шестидесятых годов, но проблема была не в технике, а в модели, а она не изменилась, т.е. дергаться в этом направлении смысла нет. А для некоторых задач она используется, слышал что как-то там юзеры через ЛДАП логинятся в оракл, говорят получается быстрее, но подробностей не знаю.

Что касается ОО у оракла и прочих, то чего не сделаешь ради денег. Маркетинг называется. Я пробовал применять ОО фишки оракла, ничего хорошего, сплошные проблемы. Реляционными методами все делается гораздо легче.

vadiminfo

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


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

vadiminfo

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


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

vadiminfo

Если полуструктурированные, тока благодаря тому что там в такой форме представлен ХМЛ, а РМД. Вы вот пример про ленту приводили, что на нее можно таблу записать. Но от этого лента не станет таблой. Так и здесь.


Можно и ленту назвать таблицей, но чтоб совсем точно это физическая модель таблицы, как и таблица на листе бумаги тоже физическая модель.

vadiminfo

Кстати одно из достоинств ХМЛ, что существуют стандартизованные методы его отображения во многие форматы в достаточны выразительном виде. Хотя это напрямую к вопросу МД может и не относится, но говорит о том, что на него сделали ставку в инфотехнолгиях. SQL, например, не нравится Дейту, но из-за этого он теперь уже не сойдет в небытие.


Это не достоинство ХМЛ-я, это достоинство стандарта, т.е. скорее достоинство реализации. То же можно было бы сделать и для реляционныой модели. Но для ХМЛ-я это легко потому что модель простая, с реляционной были бы трудности, но преодолимые.

Я совсем не против ХМЛ-я, но только когда он на своем месте. Я против того, что его выставляют как открытие века и универсальное средство от всего, пытаются на нем строить базы даных, один раз наблюдал где-то тут восторженного идиота который собирался вкладывать в ХМЛ всю вселенную. Очень напоминает шум вокруг ООП-а, что получилось все знают. Только идея у ХМЛ-я еще беднее.
13 июн 05, 11:21    [1616722]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

А где я говорил про триггеры? Есть определение СУБД, не бязательно реляционной, данное Коддом по-меому, оно тут многократно цитировалось.Там гаворится что СУБД должна поддерживать целостность данных и еще много чего. Версант на сервере целостность не поддерживает. Следовательно сервер без клиента не СУБД. Можно к серверу прилепить клиент и это все попытаться назвать сервером, как это делал Alexey Rovdo, но тогда нарушается другой пункт этого определения, что доступ к данным осуществляется токлько через сервер. Вы же участвовали в этой дискуссии и по-моему доказывали что версант не СУБД.

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

Я высказывал мысли, что Мумпс не СУБД. Это было. Так он и в литре упоминается как язык программирования, а не СУБД.

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

c127

Какие исследования, уже обожглись один раз, на иерархической модели, зачем еще раз наступать на те же грабли. Бедная модель, почти ничего туда хорошо не ложится. Техника стала лучше с шестидесятых годов, но проблема была не в технике, а в модели, а она не изменилась, т.е. дергаться в этом направлении смысла нет. А для некоторых задач она используется, слышал что как-то там юзеры через ЛДАП логинятся в оракл, говорят получается быстрее, но подробностей не знаю.

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


c127

Что касается ОО у оракла и прочих, то чего не сделаешь ради денег. Маркетинг называется. Я пробовал применять ОО фишки оракла, ничего хорошего, сплошные проблемы. Реляционными методами все делается гораздо легче.

Но то, что сегодня нельзя получить ничего хорошего, не означает что и завтра не получат. В Орале ОО развивается от версии к версии. Сегодня да - там много ограничений. Например, не приятно, что такие типы не могут участвовать в репликации. Ну какое это имеет отношение к самому ОО? Я считаю, что они просто специально хотят навредить русским.) Кто еще будет применять ОО, или все что Оракл понапихал, не выясняя заранее всех обстоятельств?

Кстати, забыл ответить про иерархические запросы в Оракле. Там именно иерархические. Рекурсивных они, по крайней мере, на 9 еще не втюхали. Конструкцию WITH уже вставили, а до конца дело не довели. (Ну не гады?)

Я не против, что маркетинг имеет место быть, но не на пустом месте.
Кроме него, может быть и еще что-то и вполне рациональное. Просто он заставляет производителей иногда, кое-где и кое-что делать не совсем последовательно. Наспех что-то прилепить и раструбить об этом, вместо того чтобы реально реализовывать.
Кроме того, ООП продолжает развиваться само по себе. Тут следует тоже с перспективой смотреть.



c127

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

В реляционной нет. Но она есть в реальном мире и ее моделируем с помощью таблиц (или отношений, если последовательно надо). Модель данных представляет сущности (хотите объекты) реального мира. Отсюда и про соттветсвие.

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

c127

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

Тем более. Я же Вам и грил, что ее не стоит игнорировать как минимум математикам. Конечно, я в серьез этого не утверждаю. Так мои предположения. Впрочем, ее же не зря в высшее образование включают.

О том что такое философия, и что там диалектика можно конечно долго грить и ни до чего не договориться. Но все-таки наиболее общие законы развития могут помочь. В частности, отрицание отрицания. Была иерархическая модель. Он господствовала (наряду с сетевой). Ну не менее 10 лет, хотя и не более 20.
Потом появилась Рел модель - отрицание. Что будет дальше? Должно быть отрицание орицания. Стал быть можно допустить появление иерархической в новом качестве. Конечно, может я не правильно применил этот закон. Но на размышления это наводит. В частности, при выяснении подробностей про ООСУБД, мы увидели, что там есть полезные признаки иерархических. Например, физические ссылки.
Правда, если более точно применять закон, то в этом новом должна все равно как-то проявиться Рел модель. Что-то от нее рационального.
Ну хоть можно что-то пытаться предполагать. Поди плохо?
13 июн 05, 15:37    [1617145]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
c127
Guest
vadiminfo

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


Акцес тоже не СУБД, я об этом говорил. Не верите - читайте классиков: //www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=72. Не меня конечно, а тех, кто в ссылках.

c127
2 Alexey Rovdo

>Т.е. мы называем одну программу "СУБД", а другую - "сервер приложений" исключительно исходя из того, для исполнения каких функций эта программа предназначена. И ваше описание функций и требований к исполнению этих функций вероятно правильное. Но речь то не об этом. Если у меня есть некий набор компонентов, программ, приложений, подпадающий под ваше описание функций СУБД, то я могу назвать его СУБД? Или, чтобы не заморачивться на названиях, есть ли какие-то еще формальные причины, по которым такой набор/программу/приложение можно отличить от того, что вы называете СУБД?

Эти формальные причины - определение СУБД. Определения под рукой у меня нет, я ориентируюсь на функции, которые СУБД должна с необходимостью выполнять. Если не выполняет, то не СУБД. У Дейта они перечислены на на стр.39-40 стр (An Introduction to Database Systems, sixth edition, Addison-Wesley, 1995), со ссылкой на Кодда. Там под номером 3 идет data security and integrity. А у Кодда (Codd E.F., "Relational Database: A Practical Foundation for Productivity", Communications of the ACM 25, no.2) это правила 6 и 8. Связка СУБД+сервер-приложений не может обеспечить целостность данных, поскольку если СУБД исползуется только как хранилище, а вся логика и целостность обеспечивается сервером приложений, то я могу совершенно легально подключиться к СУБД с другого сервера приложений, который о целостности ничего не знает, и нарушить эту целостность. Поэтому такую связку в строгом смысле нельзя назвать СУБД. Если же целостность и логика хранится в СУБД, например в СКЛ сервере, то другим СКЛ сервером Вы уже не подключитесь.

Тут об этом уже говорилось, я просто подчеркиваю, что это нарушает определение СУБД.



vadiminfo

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


Речь не об успехе или неуспехе, речь о запихивании ХМЛ-я во все дыры, куда нужно и куда не нужно. А дураков много и на высшем уровне. К тому же не нужно забывать, что единственная задача любого бизнеса без исключения не развитие технологии, а получение прибыли. Если с плохой технологии можно срубить немного бабок, то почему бы и нет.

vadiminfo

В реляционной нет. Но она есть в реальном мире и ее моделируем с помощью таблиц (или отношений, если последовательно надо).


В реальном мире тем более нет, там вообще нет определений.

vadiminfo

Но в каждый раз они вложены в рел таблицу. Это просто формат такой.
Вы говороите, можно ХМЛ в рел таблы затолкать. Но колонки этих рел табл, разве соотвествуют свойствам реальных сущностей?


А где сказано, что колонки должны соответствовать свойствам сущностей?

vadiminfo

Тем более. Я же Вам и грил, что ее не стоит игнорировать как минимум математикам.


Так нету же независимого понятия и науки "философия". Есть совокупность наук, называемых "философия", туда входит и математика. По-моему это правильно.

vadiminfo

Так мои предположения. Впрочем, ее же не зря в высшее образование включают.


Не знаю как сейчас, раньше включали из идеологичеких соображений, как и такие науки (!) как научный атеизм и политэкономию социализма. Мне моё знание философии не помогло ни разу ни в науке ни в жизни.

vadiminfo

О том что такое философия, и что там диалектика можно конечно долго грить и ни до чего не договориться. Но все-таки наиболее общие законы развития могут помочь. В частности, отрицание отрицания. Была иерархическая модель. Он господствовала (наряду с сетевой). Ну не менее 10 лет, хотя и не более 20.
Потом появилась Рел модель - отрицание. Что будет дальше? Должно быть отрицание орицания. Стал быть можно допустить появление иерархической в новом качестве.


По-моему этот закон в философской интерпретации есть пустой набор слов, как и все остальное в марксистко-ленинской философии. Он мне больше нравится в математической формулировке: (not (not X)). Просто и понятно, о появлении новых сущностей речи нет. По-моему у наших доморощенных философов (Маркс-Энгельс-Ленин и примкнувшие к ним) просто не хватило мозгов разобраться о чем тут идеть речь, вот выдумали новый закон под названием "отрицание отрицания".

А то что все развивается по спирали было известно за пару тысяч лет до них.

Я так и не понял, что такое полуструктурированные данные? Можете объяснить поконкретней? Это по-Вашему единственное существенное отличие ХМЛ-я от иерархических БД?
14 июн 05, 03:58    [1617754]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
Bald
Member

Откуда:
Сообщений: 52
О неструктурированных и квазиструктурированных данных :
http://www.osp.ru/os/2002/09/057.htm
14 июн 05, 11:19    [1618330]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
vadiminfo
Модель данных представляет сущности (хотите объекты) реального мира.

Это не так.
Модель данных (МД) — это обобщенная теория представления данных, включающая:
• элементы структуры
• операторы (правила вывода)
• правила целостности.
Например, реляционная модель данных:
• домены, отношения, атрибуты, кортежи
• реляционная алгебра
• система ОЦ уровня домена, атрибута, отношения и БД, в том числе частные случаи ОЦ:
ОЦ потенциального ключа и ОЦ внешнего ключа.
Таким образом, МД сама по себе есть просто концепция. Она, разумеется, не представляет конкретные «сущности» реального мира. Она позволяет представлять данные о реальном мире в виде БД, построенной на принципах этой МД. Но это не значит, что, скажем, каждый кортеж РМД должен соответствовать «сущности реального мира». Каждое отношение имеет предикат, задающий «смысл» кортежей отношения. К примеру, отношение Employee (ID, Name, Age) может иметь предикат «Сотрудник с идентификатором ID имеет имя Name и возраст Age». Кортежи отношения представляют факты, удовлетворяющие предикату. Например, кортеж < ID=177, Name=Johnson, Age=31> представляет факт: «Сотрудник с идентификатором 177 имеет имя Johnson и возраст 31». Таким образом, эти факты как частный случай (как в этом примере) могут в некотором смысле «соответствовать» сущностям реального мира, но в общем случае не обязательно. Это могут быть факты о каких-то аспектах сущностей, об их связях друг с другом.
14 июн 05, 14:02    [1619072]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
Андрей Леонидович
Guest
1. Вряд ли можно придумать "что-то", чего нельзя "записать в реляционной схеме". А вот в "иерархической схеме", как раз, не все можно "записать"...
Не "почти ничего", а "вообще ничего" "туда хорошо не ложится"...

2. Почти 100% "прогеров" являются "юзерами" (программ других "прогеров"). Так что адекватных среди них, автоматически, не более 15 %...
Хотя, по моим данным, настоящие "юзеры" (которые точно не "прогеры") адекватны ВСЕ...

3. "Отношения должны соответствовать типам сущностей, если это модель."
Но с127 начеку: "таблицы сущностям соответсвовать не могут." И зря Кодд все время пытался об entity рассуждать.
И mir тут как тут: "ОЦ потенциального ключа" и "ОЦ внешнего ключа". Очень красиво. Если бы не Кодд с "entity integrity".
А дальше просто блеск: "Кортежи отношения представляют факты..." О:
1) сущностях;
2) аспектах (???) сущностей;
3) их (???) связях (???) друг с другом.

"И эти люди называют себя математиками"...

4. Будут ли соответствовать колонки "реляционных" таблиц свойствам "реальных сущностей", если XML "затолкать" в "реляционные" таблицы ? Будут. На все 100%. Либо свойствам сущностей, либо свойствам связей между сущностями...

5. Не следует использовать в качестве логической модели данных так называемые иерархичесскую и сетевые модели. Это давно известно. И хорошо известно - почему не следует. Однако для обработки, промежуточного и постоянного хранения данных иерархические базы наиболее эффективны (похоже, для большинства классов задач). В частности, "объекты" (и в классическом понимании, и в понимании ООП, и "слабоструктурированные", и "сложноструктурированные") очень удобно хранить в структурах, подобных глобалам Cache. Причем "традиционные реляционные кортежи" "без потерь" (в сравнении с "собственно реляционными" СУБД) можно хранить в ЭТИХ ЖЕ структурах. Таким образом, имеем и связи многие-ко-многим, и объектную навигацию, и, при необходимости (которую никому так и не удалось обнаружить ни для одного типа приложений !), SQL-доступ...

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

P.S. "Серьезная литра" ! Видимо (надеюсь), которая дает достоверную и непротиворечивую информацию... Вот бы почитать...
14 июн 05, 19:18    [1620290]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

Акцес тоже не СУБД, я об этом говорил. Не верите - читайте

То что Вы это говорили, я верю, то что Аксцесс не СУБД - не верю. Тем более его в толстых книгах называют СУБД.
А СУБД первого поколения - тоже не СУБД?
Наши с Вами любимые иерархические - например, IMS?
Там зависмость от данных поболее будет. Все-таки понятие СУБД появилось до 1970 года. Термин зарезервирован - если не подходит, надо другой придумывать, а потом раскрутить его.
Что касается ограничений целостности, то нигде не говорится до каких пределов СУБД их должна поддерживать.

c127

В реальном мире тем более нет, там вообще нет определений.

Ну может тогда нет и самого реального мира, раз определений нет? И самих определений тоже нет, так как рано или поздно мы нарвемся на что-то не определяемое в его опрделении? А Вы говорите, что философия не Ваше кредо. Вот она самая.
Хорошо, возьмем пока реальный мир в ковычки "Реальный мир".

c127

А где сказано, что колонки должны соответствовать свойствам сущностей?

Вот тут на форуме полно споров о суррогатных ключах. А ведь главная проблема этих ключей, что они не соответсвуют никакому свойству сущности.
Т.е. появляется термин суррогатное свойство. Искусствено привистованное.
Это ухудшает модель. В пределе, если в модели нет нет ни свойств, ни сущностей, то модель слишком плоха, чтобы называться моделью. Зато термин формат к этому равнодушен.
Если модель данных нужна не для того, чтобы представлять "реальный мир" объектов и событий и связей между ними (а они имеют свойства), то зачем же еще? Все остальное как бы хорошо не было, скорее всего, обошлось бы без термина "модель".


c127

По-моему этот закон в философской интерпретации есть пустой набор слов, как и все остальное в марксистко-ленинской философии.

Это не в Марксистко-Ленинской, а в объективно-идеалистической Гегелевской. А Маркс И Ленин не дураки были, чтобы все это взять в свою в виде составной части.
Вы слишком категоричны - это достижение человеческой мысли уже.

c127

Он мне больше нравится в математической формулировке: (not (not X)).

Это закон формальной логики. Именно он и подвергся в первую очередь критике, когда Рассел с его помощью нашел знаменитый парадокс в Канторовской теории множества.
А я Вам закон диалектики подбрасывал. Другое совсем дело.

c127

Я так и не понял, что такое полуструктурированные данные? Можете объяснить поконкретней? Это по-Вашему единственное существенное отличие ХМЛ-я от иерархических БД?

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

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

Были и раньше попытки создания СУБД для слабоструктурированных данных (Lorel)

Модели данных давно делят на сильнотипизированные и слаботипизированные. У одних они преимущеста и недостаки у других другие.
В, частности, манипулировать легче первыми, и в пределе для РМД - есть вообще рел алгебра. (Впрочем, W3C предложила алгебру запросов XML). У полуструктурированных - большая гибкость.

Это концептуалное отличие, но не только от ирархичеких, а от структурированных вообще, в том числе и иерархических.
Реально мало кто сравнивает ХМЛ с иерархическими.
Берите выше.

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

2 mir
Я имел ввиду в том вопросе семантический и прагматический аспекты моделей данных.
Конечно и связи и события она может представлять. Ясное дело.
Там речь шла о противопоставлении РМД реляционному формату. А формату, кстати говоря, и формальный (теоретический, синтаксический) и прочие аспект тоже сам по себе безразличны. Хотя есть типы, есть ограничения, есть язык программирования, который может работать с этими форматами данных.
Их главная цель упростить программирование.
У Ворда тоже есть и элементы структуры, операторы ввода, правила целостности в том или ином виде. Но это не модель данных.

Чистые формальные теории обретают пользу, и тем самым оправдывают свое существование, только благодаря интерпретации. Для моделей данных семантика имеет значение, иначе слово "модель" не оправдано. Говорили бы формальная теория данных. И не было бы вопросов.
14 июн 05, 21:48    [1620548]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
c127
Guest
vadiminfo

То что Вы это говорили, я верю, то что Аксцесс не СУБД - не верю. Тем более его в толстых книгах называют СУБД.
А СУБД первого поколения - тоже не СУБД?


Дело не в том я говорил или еще кто. Дело в том, что есть определение Кодда. Соответствует - СУБД, не соответсвует - не СУБД. А толщина книги от количества мозгов у писавшего зависит слабо.

vadiminfo
c127

По-моему этот закон в философской интерпретации есть пустой набор слов, как и все остальное в марксистко-ленинской философии.

Это не в Марксистко-Ленинской, а в объективно-идеалистической Гегелевской. А Маркс И Ленин не дураки были, чтобы все это взять в свою в виде составной части.
Вы слишком категоричны - это достижение человеческой мысли уже.


Маркс с Лениным были дураками в математике, а Ленин был дураком вообще. Почитайте переписку Маркса с Энгельсом о бесконечно малых, четкое впечатление что переписываются два дебила. В экономике может и разбирался, а в математике нет. А чтоб составить впечатление о Ленине достаточно полистать (можно даже не читать, впечатление не изменится) его главный философский труд "Материализм и эмпириокритицизм". Базарная ругань в прямом смысле этого слова и 0 смысла. В тот момент он уже не очень представлял где он находится по-моему.

vadiminfo

Это закон формальной логики. Именно он и подвергся в первую очередь критике, когда Рассел с его помощью нашел знаменитый парадокс в Канторовской теории множества.
А я Вам закон диалектики подбрасывал. Другое совсем дело.


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

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

vadiminfo

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

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


Я понял. Вопрос: речь идет о структуре данных или о том что структура известна, но неизвестны типы?

В любом случае это легко записывается в РСУБД. Правда Вы эту структуру не называте реляционной. Но проблема в том, что данные все равно в какой-то момент нужно структурировать. Т.е. просто работа переносится с проектировщика БД на конкретного программиста или кто там потом работает с БД. За гибкость в начале проектировани нужно платить на другом этапе. Т.е. наша задача уменьшить общую трудоемкость, а она в данном случае не уменьшается, а только увеличивается за счет путаницы, которая обычно возрастает по мере продвижения проекта.
15 июн 05, 01:45    [1620692]     Ответить | Цитировать Сообщить модератору
 Re: Вопросы сравнения XML-БД и плоскотабличных БД...  [new]
vadiminfo
Member

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

Дело в том, что есть определение Кодда. Соответствует - СУБД, не соответсвует - не СУБД.

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

Почему Вы ничего не говорите о том, что СУБД вообще появилось раньше 1970 года и предложено группой Кодасил? Их вроде как бы слово первое что есть СУБД вообще. Вряд ли Кодд это оспаривал.
Может тока СУБД второго покаления или будущие.

c127

Так я ж и говорю, был закон логики, его не разобравшись всунули в философию.

Думаю, все-таки, что Гегель это слишком серьезно, чтобы говорить о том, что он не разобравшись что-то сделал.
В формальной логике все рассматривается в одном и том же смысле, и в одно и то же время. А там диалектика - все рассматривается в развитии. Даются общие методы познания.
Впрочем, дело веры.

c127

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

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

c127

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

В РСУБД записывается, возможно, легко. Структуру назваю реляционной. Формат называю реляционным, даже если затолкали в Йексесль, но реляционную таблу. Не называю произвольную совокупность рел табл реляционной моделью в общем случае.
Т.е. речь шла о том, что простое заталкиваение модели данных ХМЛ в РСУБД
не есть еще отображение на реляционную модель данных. А запихать можно не тока в РСУБД, а в тот же йексель или ворд.

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

c127

Вопрос: речь идет о структуре данных или о том что структура известна, но неизвестны типы?

О том, например, что про одного автора в листе дерева написаны ФИО слитно, а для другого отделно три листа (Ф, И, О) и еще четвертый про гонорар. Полхо формализованная модель.

В реляционной модели данных - есть заранее фиксированная схема. А в полуструктурированной, как правило, нельзя данные описать с помощью какой-то неизменной схемы. Характерной особенностью слабоструктурированных данных опистельная информация присутствует в самих данных, а не отделяется от них как в структурированных.
Затолкать это в 6 рел таблиц, наверное, можно, а отобразить на рел модель сложновато будет, и модель получится корявая. А потом схему постоянно менять придется? А тех 6 табл самих по себе не достаточно, нужно все равно знать про ту модель что внутри у них, чтобы извлекать нужные данные как можно проще. Например, найти все книги автора.
15 июн 05, 20:43    [1623201]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить