Здравствуйте все.

Данным топиком хочу поддержать незаслуженно забытые встраиваемые СУБД, такие как Berkley DB (http://www.sleepycat.com) или пока малоизвестная, но не менее функциональная Nimble Embledded Edition (www.vrg.ru).


С уважением,
Боронин Сергей

Чем хорошие? Да хотя бы тем, что их очень удобно распространять вместе с дистрибутиваи программ их использующих.
Они очень быстрые, хотя и менее мощные чем MS SQL и Oracle.
Они очень удобны для так называемой "портфельной" обработки данных, т.е. когда данные получаются из общей базы во встраевуемую, что удобно для мобильных сотрудников, а по возвращении, они заливаются в общую базу.
Для однопользовательских версий.
Им есть множество применений.

Скачайте Nimble 0.1 Embedded Edition да попробуйте его сами
Качать здесь: http://ftp.vrg.ru/pub/ru/vrg/nimble/releases/0.1%20Embedded/nimble-embedded.0.1.zip

2 Павел Воронцов

>Это ежу понятно, что менее мощные. Параметры плиз - количество хранимых >записей, какой диалект SQl поддерживается и т.д.
>

Ответы на эти вопросы зависят от конкретной встраиваемой СУБД и могут сильно варьироваться, это во-первых. Во-вторых, почему вы считаете, что они обязательно реляционные? В часности Berkley DB и Nimble не являются реляционными СУБД и, соответственно не поддерживат SQL-доступ, вместо него они предоставляют собствнный API на С++. Ограничение на размер базы данных 2^64 байт.
по быстродействию Oracle и MS SQL примерно на порядок медленнее.

>А теперь ещё раз - какие средства интеграции? Есть ли к ним ODBC драйверы, >ADODB провайдеры или ещё какие-нибудь общепринятые интерфейсы? Могут ли >они выгружаться в/загружаться из csv файлов, есть ли у них встроенные >механизмы синхронизации?
>

На сегодняшний день ODBC или ADODB интерфейсов нет, да и не нужны они не реляционным СУБД, есть свои API на С++, а следующей версии Nimble появится поддержка XMLDB:API

2 ALL

На реляционках свет клином не сошелся!

Ничем, насколько мне известно, причем насколько мне известно никто и не хаит.
Только что вы называете cтандартным доступом?

2 Павел Воронцов
>Плохо тем, что они умрут довольно скоро. Именно из-за своей нестандартности и >нереляционности.
>

Вынужден с вами не согласиться, т.к. вымирание ожидает реляционки, как морально устаревшие, а BerkleyDB и Nimble двигаются в направлении бинарных XML-based СУБД см. www.xmdb.org

2 ASCRUS
>Можно посмотреть в сторону Sybase ASA, у них там полный комплект поддержки >мобильных и встраиваемых решений.
>
Опять-таки реляционка, а реляционки вымрут как динозавры.
Тот же Oracle все больше и больше риентируется на XML, Microsoft тоже поддержала преобразования SQL2XML, да и в .Net без XML ни шагу.

2 Alll
XML - это будущее, а не SQL
Поэтому пора начать смотреть на альтернативы.

С уважением,
Боронин Сергей

>Чьё будущее ?? Будущее всех БД ??
>

Да

>Угу, щаз все программеры для всех баз кинут скуль и будут педалить на xml.
>НЕ ДОЖДЕТЕСЬ.
>

:)) Что вы имеете против XML?

>И не представляю я как можно вместо скуля юзать хмл.
>

Думаю что все дело именно в этом....
Т.к. если бы вы знали насколько это удобно работать средствами DOM, то не писали бы того, что написали.

>Да и учить под каждую СУБД свой АПИ интерфейс не есть гуд.
>Скуль он и есть скуль. Да, множество деталей между теми же транзакт и ПЛ, но >суть-то одна.
>
XMLDB:API он и есть XMLDB:API см. www.xmldb.org
и он гораздо гибче и да вы почитайте, после этого у вас исчезнет высокомерное отношение к XML

>Так что, имхо, Вы погорячились
>
Нет, я стараюсь быть объективным, подробности в моей следующей мессаге.

С уважением,
Боронин Сергей

2 Павел Воронцов

>Я придерживаюсь прямо противоположной точки зрения. То, что Оракл и MS >SQL >поддались общей моде на XML ещё ничего не значит. Оракл в 90е годы >вон начал >было поддерживать ООДБ расширения, но ничего путного из этого >не вышло.
>

XML это не мода - это будущее, в MS и Oracle не дураки же сидят. А ООБД свое еще возьмет, наример Cache и Fast Objects живут себе и здравствуют.

>XML никак не альтернатива реляцинным БД. Он НИЧЕГО нового по сравнению с >уже давным-давно известными и (уже) проигравшими в конкуретной борьбе >сетевыми БД не приносит. Назовите мне пожалуйста преимущества XML DB, >которые позволят им выиграть у реляционных систем?
>

Почитайте спецификацию XMLDB:API (www.xmldb.org), думаю вы измените свое мнение.

2 VF

>а ещё не вспомнили совместимость ПО уже написанного... кто будет его >переписывать?
>

На xml будут переходить постепенно в новых версиях этого ПО

2 f2f

>Скачал я эту nimble
>Пока это не тянет даже на дипломную работ
>

Сомнительно, чтобы за столь короткий период времени вы смогли в ней разобраться. Или вы считаете, что все что не имеет SQL-интерфейса must die? :))




С уважением,
Боронин Сергей

2 Glory

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

С уважением,
Боронин Сергей

>Нет уж, раз Вы взялись тут поддерживать данное направление, то и оттдувайтесь >:) Хочется услышать из Ваших уст. Просто сформулируйте кратко, по пунктам, >ЧЕМ XML DB лучше реляционных. А мы поспорим.
>
Зачем мне пересказывать, то что и так хорошо описано.
Если возникнет интерес - почитайте, чтобы завтра вы могли со мной предметно поговорить.
А сегодня мне уже пора убегать, до завтра.

С уважением,
Боронин Сергей

Доброе утро, всем.

2 Павел Воронцов

>Нет уж, раз Вы взялись тут поддерживать данное направление, то и оттдувайтесь >:) Хочется услышать из Ваших уст. Просто сформулируйте кратко, по пунктам, >ЧЕМ XML DB лучше реляционных. А мы поспорим.
>

Вот неполный список преимуществ:

-- Нормализованные БД на binary XML-based можно обрабатывать используя XMLDB:API без потери в скорости выборки, в отличие от реляцтонок которые теряют в производительности при нормализации, особенно если это 4НФБК или 5НФ

--Меньше требуется кода для поодержки целостностид связанной с нормализацией

--Более естественное, древовидное представление данных

--Работа с DOM-объектом удобнее, чем с кучей рекордсетов, предоставляющих тот же набор данных

--Для получения тех же данных требуются более простые запросы, например для получения счета достаточно сделать 1 XPath-запрос к базе, при этом будет получена и шапка счета и детали счета.

--С сохранением измененых данных тоже проблем никаких, либо сохраняется целиком DOM-объект, либо используется xpath-запрос, и хотя xpath не входит в DOM2, но он есть в XMLDB:API

--XML гораздо легче ложится на объектную структуры, чем SQL

--XML позволяет легко и естественно работать с n-мерными данными, а в "плоском" SQL для этого надо изголяться

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


2 Glory

>Если после этого все обращения к данным пойдут только через движок БД, то >это уже не будет XML.
>
Почему? Engine, реализующий XMLDB:API оперирует DOM-объектами, которые являются объектным представлением XML.

>А если не пойдут - то это будет второй DBF формат(более мощный/гибкий и пр.) >но всего лишь формат ХРАНЕНИЯ. А в БД формат хранения не первое дело.
>
Ну вручную парсить XML или его бинарное представление никто не будет, все операции пойдут через движок реализующий XMLDB:API, а уж чем пользуется движок для храннения данных XML-файлом или бинарной базой это дело десятое и формат хранения, как вы верно заметили, не первое дело.

>Вахххх...!!! Напишите ка селект из трех таблиц со вложенными селектами и 15 >условиями с парочкой case-ов, а мы на это посмотрим.
>

В XML нет таблиц, они там и не нужны, зато для есть xpath и xupdate, с помощью которых не надо так извращаться :)
Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!

>Настолько удобно работать через DOM, что штаны через голову легче одевать.
>

См. выше.

>Не говоря уж о тормозах.
>

Не обязательно XML-данные хранить в текстовом виде, можно и в бинарном

>Да и вообще - что, мода теперь такая, XML? Это как java несколько лет назад - >все предрекали на джаве будет. И где оно?
>
Так, java сейчас рулит вовсю, мешая .Net :)
Orale 9i усилили поддержку java по сравнению с 8-й версией, а в 10g упор вооще сделан на java а не на PL/SQL.
Да и MS в Yukon обещает возможность писать процедуры на C#, как замене SQL и тоже наращивет поддержку XML

2 f2f

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

Тут вы правы документации нет, только описание API, но это временно, т.к. VRG проект молодой

2 AAron

>Но как-то нет желания пытаться сравнить MS SQL и Fast Objects. Они для >разных вещей предназначены.
Почему вы считаете что их нельзя сравнивать и они для разных вещей предназначены?

>А сравнивать XML и сервер БД на мой взгляд некорректно. XML - язык разметки, >если кто не помнит.
>

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

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

Описать в нем можно что угодно, в том числе и бизнес-правила, а вот обрабатываться они будут на уровне движка, конкретной XML-based СУБД
Ведь dbf-файлы не позволяют описать бизнес правила, но это можно поручить программе их обрабатывающей.

2 vdimas

>Боронин Сергей, просьба прореагировать на вопрос нормально, тебе сколько >лет?
>

Раз уж мы с вами перешли на ты. :))
27 лет и 10 лет стажа, сначала как разработчик, потом как менеджер проекта, было что и IT-отделом рулил на прежней работе.
А тебе сколько лет?

>Ну как ты будешь делать множественную выборку со сложной логикой на XML? >Ну никак, поверь мне. Только "ручками" бесконечно перелопачивая этот >проклятый DOM.
>
Ты про XPath слышал, если да то соотнеси с тем, что я ответил Павлу Воронцову и подумай, что наверное у "гиперсложных" реляционных проблем бывают и простые XML-решения.

>Рискую нарваться на резкости, но на мой взгляд - это не самое эффективное >решение. (если, конечно, разговор вообще ведется об эффективности). Дело в >том, что структурный бинарный файл со спец структурой читается самописным >разборщиком на ПОРЯДОК быстрее самых быстрых XML парсеров и занимает в >памяти НА ДВА ПОРЯДКА меньше места. Хотя, на этапе прототипирования, XML >здорово выручает.
>
Относительно быстродействия и объемов памяти это вопрос конкретной реализации, а вот придумывать свой бинарный формат, когда есть стандарные решения, это не профессионально!
Тем более что XML-данные могут храниться не только в текстовом виде, но и в бинарном, соотвественно брабатываться не менее быстро и да и по памяти компактно. Смотри в сторону Berkley DB XML (www.sleepycat.com)

2 Ermak

>Дайте четкое определение, что такое ''XML база данных".
>

XML база данных, это база данных текстовая или бинарная к которой есть движок, предоставляющий XMLDB:API

2 eNose

>А XML файл справится с данными объемом 20 GB?
>А 200 GB?
>Вот всякие там ораклы, скуль, сайбезы - справляются и с бОльшими объемами..
>

Вы говорите про текстовый XML-файл или СУБД с XMLDB:API?
Текстовый XML-файл не справиться, а СУБД, зависит от реализации, например Berkley DB XML справится с 2^64 байт, что гораздо больше.
Думаю, что ответил на ваш вопрос.


С уважением,
Боронин Сергей

2 eNoise

http://www.sleepycat.com/products/xml.shtml

С уважением,
Боронин Сергей