Меня уже почти год мучает вопросы связанные перспективами развития БД.
Началось все когда делал диплом. Это была обучалка по технологии программирования. Обучалка не совсем такая к которым все привыкли. Главная в ней часть (фича, изюминка) -"интеллектуальный" тренажер. Строишь себе UML диаграмму по заданию, а помощник (как в Office) тебя поправляет и "ценные" советы дает. Ессесенно там кое-чего из алгоритмов ИИ было (как сильнодействующее на комиссию средство, да и просто интересно), трехзвенка с собственным сервером приложений и т.д. и т.п.
Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко). Физически попробовал сначала сделать реляционную структуру для описания задания, но понял что запутался — взял XML за основу проект разом упростился. Сделанный вывод: реляционный подход в хранении данных не для всех задач хорошо.
Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
30.03.04 14:06: Перенесено модератором из 'Философия программирования' — _MM_
Здравствуйте, Morgun, Вы писали:
M>Меня уже почти год мучает вопросы связанные перспективами развития БД.
M>Началось все когда делал диплом. Это была обучалка по технологии программирования. Обучалка не совсем такая к которым все привыкли. Главная в ней часть (фича, изюминка) -"интеллектуальный" тренажер. Строишь себе UML диаграмму по заданию, а помощник (как в Office) тебя поправляет и "ценные" советы дает. Ессесенно там кое-чего из алгоритмов ИИ было (как сильнодействующее на комиссию средство, да и просто интересно), трехзвенка с собственным сервером приложений и т.д. и т.п. M>Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко). Физически попробовал сначала сделать реляционную структуру для описания задания, но понял что запутался — взял XML за основу проект разом упростился. Сделанный вывод: реляционный подход в хранении данных не для всех задач хорошо.
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
Я лично высажу свое мнение. Изначально была делема между иереархическими БД и реляционными. Первая поддерживала естественную ссылочную адрессацию, которая поддерживала скорость, и ООП которого тогда не было.
Победил уневерсализм и репликация. Скорость была предана на алтарь универсальности и доступности Юзерам. SQL прекрасно вписывается в реляционность. XML вообще отстой проповедуемый M$. То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало. Пьян.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Morgun, Вы писали:
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
О-о-о, наш человек, наш. Все, сдаю английский и начинаю новую жизнь. Мое мнение высказано здесь.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Наверное это национальная забава — поиск единственного
верного учения, методологии, языка программирования, ОС и пр...
Нет и не будет универсального, удобного на все случаи
жизни способа представлять данные.
Конечно же, реляционное представление не может быть одинаково
хорошим для любых задач, так же как и XML.
Я понял, что у тебя возникла проблема, как эффективно хранить много деревьев.
Из моего лично опыта, в ИИ довольно часто встречается такая проблема.
Попытаюсь описать эту проблему немного иначе.
Частенько при создании сложных систем (не обязательно ИИ)
есть некое явное, компактное и понятное описание метамодели знаний (иногда говорят о метазнаниях)
и нужно эффективно работать с множеством частных случаев этой метамодели (instance).
Когда все это обсуждается на бумаге и не задумываются о реализации,
то нам доступны не только теории 1-го порядка (например исчисление предикатов 1-го порядка),
но и теории 2-го и более высоких порядков.
Что мы имеем доступного на компьютерах?
Увы, ничего выше первого порядка мы реально работающего так и не имеем.
Реляционные базы — это система первого порядка.
Думаю одна из причин твоих проблем лежит в этой плоскости.
Современные копьютеры очень плохи для описания метамоделей,
метаметамоделей и далее.
Как эффективно на современных компьютерах реализовать например
исчисление предикатов 2-го порядка — это пока нерешенная проблема.
Уверен, будь у тебя эффективная ООСУБД, ты бы в итоге столкнулся
с похожими проблемами, что и с реляционными БД.
Здравствуйте, Serginio1, Вы писали:
S> Я лично высажу свое мнение. Изначально была делема между иереархическими БД и реляционными. Первая поддерживала естественную ссылочную адрессацию, которая поддерживала скорость, и ООП которого тогда не было.
Ну если так — были еще и так называемые сетевые БД (иерархические их частный случай). Однако ОО поддерживать они не могли — его как ты сказал не было. Это дела давно минувших дней.
S> Победил уневерсализм и репликация. Скорость была предана на алтарь универсальности и доступности Юзерам. SQL прекрасно вписывается в реляционность. XML вообще отстой проповедуемый M$. То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало. Пьян.
Тогда победил структурный подход. А репликацию ты по-моему зря сюда присоединил (это вообще ко всему относится, а не только к реляционным).
S> SQL прекрасно вписывается в реляционность.
Еще бы SQL не вписался — он проектировался под реляционное исчисление.
S>XML вообще отстой проповедуемый M$. Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
S>То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало.
Яндекс — это если правильно понял не документооборот, а поисковая машина.
2 дня в упор — в самый раз. Учти — диплом защитил на ура — теперь кондидатскую писать буду.
1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме.
2. Слабые выразительные возможности. Если в системе невозможно в явном виде отобразить ту или иную информацию, то это приводит либо к потере данной информации, либо к ее искажению, что в свою очередь влечет за собой построение "упрощенной" модели, отображающий не саму задачу, а "взгляд" на решение задачи с позиции текущих требований.
3. "Жесткость" структур хранения информации...
Для решения этих (и других проблем) в нашем коллективе разработана База Знаний, с собственным языком описания знаний. Есть реализованные коммерческие проекты.
Так что эта тема нам очень даже близка
Если есть вопросы — пишите...
Здравствуйте, Аноним, Вы писали:
А>Наверное это национальная забава — поиск единственного А>верного учения, методологии, языка программирования, ОС и пр... А>Нет и не будет универсального, удобного на все случаи А>жизни способа представлять данные. А>Конечно же, реляционное представление не может быть одинаково А>хорошим для любых задач, так же как и XML.
Ты меня не правильно понял. Моя задача — не найти универсальное решение, а очертить круг для которого то или иное (реляционное или нереляционное) решение подходит лучше. Что в моем дипломе XML оказался лучшим решением, чем реляционная структура — это я доказал.
А>Я понял, что у тебя возникла проблема, как эффективно хранить много деревьев.
А>Из моего лично опыта, в ИИ довольно часто встречается такая проблема. А>Попытаюсь описать эту проблему немного иначе. А>Частенько при создании сложных систем (не обязательно ИИ) А>есть некое явное, компактное и понятное описание метамодели знаний (иногда говорят о метазнаниях) А>и нужно эффективно работать с множеством частных случаев этой метамодели (instance). А>Когда все это обсуждается на бумаге и не задумываются о реализации, А>то нам доступны не только теории 1-го порядка (например исчисление предикатов 1-го порядка), А>но и теории 2-го и более высоких порядков. А>Что мы имеем доступного на компьютерах? А>Увы, ничего выше первого порядка мы реально работающего так и не имеем. А>Реляционные базы — это система первого порядка. А>Думаю одна из причин твоих проблем лежит в этой плоскости. А>Современные копьютеры очень плохи для описания метамоделей, А>метаметамоделей и далее. А>Как эффективно на современных компьютерах реализовать например А>исчисление предикатов 2-го порядка — это пока нерешенная проблема.
Очень точно все разложил по полочкам. Я интересовался вопросами ООБД и в частности их математическими аспектами. Все так как ты сказал. Нужны системы высших порядков. В частности с исследованиями этих областей знаний связывались разработчики ООБД. Некоторые даже достигли успехов, хоть и небольших.
А>Уверен, будь у тебя эффективная ООСУБД, ты бы в итоге столкнулся А>с похожими проблемами, что и с реляционными БД.
Да я и не спорю. Но у меня стоит конкретная задача — документооборот. Я думаю тут таких больших проблем с "порядками" не возникнет. Моя задача — заложить в систему гибкость и мне кажется реляционная база — путь к неуспеху (а может быть и провалу) проекта.
P.S. Если тебе известны некоторые публикации о тех вопросах, которые ты затронул — перечисли их, пожалуйста. Я буду очень признателен.
Здравствуйте, Аноним, Вы писали:
S>>XML вообще отстой проповедуемый M$. А> Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
В написании стандарта принимал участие в том числе и человек из микрософт.
Хотя это конечно же не гововрит о том что xml--отстой.
Здравствуйте, bravo, Вы писали:
B>На самом деле в реляционных БД больше проблем
B>Вот самые существенные на наш взгляд:
B>1. "Бессмысленность" данных, хранящихся в БД, т.е. интерпретация "смысла" данных в БД лежит либо непосредственно на пользователе, либо на прикладном алгоритме.
Это может рассматриваться и как достоинство.
Хранить данные лучше отдельно от их интерпретации.
Сегодня ты можешь данные проинтепретировать одним
образом и сделать одни выводы, а завтра — совсем иначе.
Данные же останутся одними и теми же..
Здравствуйте, Morgun, Вы писали:
M>Но не в том вопрос. Требование которое я изнально себе поставил — наполняемость системы. Т.е. преподаватель должен мочь новые задания описывать и в систему вводить. Вопрос — как хранить? Думал долго — 2 дня в упор. Пришел к выводу, что пока лучше сделать хранения в "алгоритмическом графе" ("И-ИЛИ" граф с вершиной-циклом) (до естественного языка мне еще ой как далеко).
В этом случае как правило данные храняться ввиде набора правил, состоящих из предиката, описывающего применимость правила и тела. Тело может быть либо написанным на алгоритмическом языке, либо какой то другой структурой, например графом, который может быть представлен тем же XML. В любом случае выбирать правило надо все целиком, а в таких условиях реляционной структуры, хранящей тело в блобе более чем достаточно.
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Как то давно, когда я был совсем молодой, видел я как вели учет наши деды, на бумаге без компьютеров. Так вот — хранили они данные исключительно в реляционном виде .
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости.
Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
Здравствуйте, bkat, Вы писали:
B>Это может рассматриваться и как достоинство. B>Хранить данные лучше отдельно от их интерпретации. B>Сегодня ты можешь данные проинтепретировать одним B>образом и сделать одни выводы, а завтра — совсем иначе. B>Данные же останутся одними и теми же
Есть обработка данных, а есть интерпретация. ;-)
В основе любой задачи лежит Модель Предметной Области (ПО), в не зависимости от того как она реализована.
Реляционные СУБД хранят только фактические данные о ПО, Объектные СУБД в основе хранят только информацию об Объектах ПО. Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации.
Для простых задач способ представления и хранения информаци не критичен, для сложных (сильно связанных) задач без "правильного" (соответствующего действительности, а не текущего взгляда на проблему) представления информации нельзя создать устойчивую к изменениям систему — приходится постоянно модифицировать исходные структуры данных. Если же использовать соответствующие семантические принципы описания информации, то можно оперировать уже абстрагированными понятиями, что делает решение задачи инвариантным к изменяющимся условиям. (О-как ;-)
P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Здравствуйте, bravo, Вы писали:
B>Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации.
Так в чем проблема?
Реляционный подход тем и хорош, что в этом представлении можно хранить любую информацию в любом количестве, причем этот подход очень хорошо формализован.
Вопрос лишь в трудозатратах.
B>P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Ну с этим не поспоришь..
Здравствуйте, AndrewVK, Вы писали:
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. AVK>Сможет, если немного повозится. Другое дело что в терминах ОО мыслить проще.
[+]
Проблема не в том, что реляционный подход недостаточно гибок, он гибок на столько на сколько это вообще возможно.
А в том, что пока не существует (а если и существует, то не реализован) универсальный механизм позволяющий переходить от реляционного представления к какому-нибудь более другому. Каждая частная задача OR Mapping'а — та еще головная боль.
Здравствуйте, Merle, Вы писали:
M>Проблема не в том, что реляционный подход недостаточно гибок, он гибок на столько на сколько это вообще возможно. M>А в том, что пока не существует (а если и существует, то не реализован) универсальный механизм позволяющий переходить от реляционного представления к какому-нибудь более другому. Каждая частная задача OR Mapping'а — та еще головная боль.
Тем не менее меппинг где нибудь делать нужно, поскольку диск принципиально плоское устройство. И ты надеешься что существует универсальный алгоритм этгго меппинга?
Здравствуйте, bravo, Вы писали:
B>Есть обработка данных, а есть интерпретация. B>В основе любой задачи лежит Модель Предметной Области (ПО), в не зависимости от того как она реализована. B>Реляционные СУБД хранят только фактические данные о ПО, Объектные СУБД в основе хранят только информацию об Объектах ПО. Реально необходимо хранить гараздо больше семантической информации для адекватного представления информации. B>Для простых задач способ представления и хранения информаци не критичен, для сложных (сильно связанных) задач без "правильного" (соответствующего действительности, а не текущего взгляда на проблему) представления информации нельзя создать устойчивую к изменениям систему — приходится постоянно модифицировать исходные структуры данных. Если же использовать соответствующие семантические принципы описания информации, то можно оперировать уже абстрагированными понятиями, что делает решение задачи инвариантным к изменяющимся условиям. (О-как B>P.S. "Понимание" смысла хранящейся информации позволяет запрашивать у системы ЛЮБУЮ информацию в терминах самой задачи (см. механизм запросов системы br-a-vo).
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
AVK> И ты надеешься что существует универсальный алгоритм этгго меппинга?
Алгоритм-то наверняка существует, проблема лишь в скорости.
Реляционный подход очень хорошо формализован, что позволило придумать для него кучу алгоритмов и вспомогательных механизмов повышающих производительность. Насколько я понимаю с объетным подходом пока что такой фокус не проходит.
Точнее может и проходит, но пока только для очень частных случаев, в то время как реляционный подход куда как более универсален и достойную производительность может показать практически на любой задаче.
А>Ну если так — были еще и так называемые сетевые БД (иерархические их частный случай). Однако ОО поддерживать они не могли — его как ты сказал не было. Это дела давно минувших дней.
Можно как угодно называть, главное принцип хранения и построения связей.
Так нормализация в РБД тянет за собой огромный индекс на подчиненные связи, где это как в нормальном программировании решается на двух напрвленными списками. Экономия на вставку и удаление, а так же надежность.
А>Тогда победил структурный подход. А репликацию ты по-моему зря сюда присоединил (это вообще ко всему относится, а не только к реляционным).
Репликация в РБД хорошо вписывается, т.к. связи построены с применением инндексов, а не прямой или коственной (номер записи) ссылки.
S>>XML вообще отстой проповедуемый M$. А> Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
Но его продвижение в Net (во многих случаях оправдан) иногда раздражает. Там где прекрасно вписывается бинарная сериализация. Еще один пример для переноса данных (репликация) и даже для хранения применяют XML. Но так как приходится его разбирать в память получают огромные тормоза. С тем же успехом можно выделять память под объекты в заранее выделенном куске памяти и доступ к объектам делать с поправкой на базовый адрес или применять отображаемые в память файлы. Причем там, где эта операция составляет несколько секунд, все происходит за 30 минут.
Теперь объясню почему мне не нравится SQL. Если посмотреть на затраты разбора инструкций Insert, Update итд при может тратится намного больше времени чем сама вставка. Я сторонник прямого доступа с ранним связыванием, особенно когда база не изменяется и не требуется работа с удаленными БД.
Рассуждения Программиста 1С. Не судите строго.
И когда приводят тесты со временем за часы сразу вспоминаю любимые ДВК-2.
Но у РБД очень много премуществ прежде всего в простоте использования и конфигурирования БД. А раз за этим еще стоят монстры индустрии то конкурирующие подходы не нужны. Хотя специализированные БД нужно писать с высокой оптимизацией с применением различных списфиских алгоритмов, где SQL и РБД сильно проигрывают особенно на сильно разветвленных БД и применеием иерархии (свинное ухо).
S>>То же документооборот решается на блобах с индексированными словосочетаниями яля Яндекс. Ну а 2 дня мало.
А> А>Яндекс — это если правильно понял не документооборот, а поисковая машина. А>2 дня в упор — в самый раз. Учти — диплом защитил на ура — теперь кондидатскую писать буду.
В документо оборот так же и входит поисковая машина. А хранеие документов в блобах самый оптимльнй путь с возможностью их быстрого поиска и классификации.
А>Если я неправ скажите.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
M>Реляционный подход тем и хорош, что в этом представлении можно хранить любую информацию в любом количестве, причем этот подход очень хорошо формализован. M>Вопрос лишь в трудозатратах.
:) ;)
В конечном итоге все к ним и сводится (трудозатратам) ;)
А репликацию ты по-моему зря сюда присоединил (это вообще ко всему относится, а не только к реляционным). 
Это ты вообще зря. Мне кажется ты его не пользовал совсем — что так заявляешь. И проповедует его далеко не MS (и уж точно не он его придумал). Он на Unix платформах вообще помоему раньше появился.
Мы уже победили, просто это еще не так заметно...
