ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Встраиваемые СУБД
25 сообщений из 76, страница 3 из 4
  3  все
Встраиваемые СУБД
    #32308664
Фотография eNose
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eNose
Участник
[не активирован]
[не одобрен]
А давайте не путать XMLDB:API, что является средством доступа, с форматом хранения.
Изначально ведь речь шла именно о формате.
А XMLDB:API можно прикрепить к чему угодно. Так же как и SQL.



eNose
...
Рейтинг: 0 / 0
29.10.2003, 12:05
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308668
sboronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sboronin
Гость
2 eNoise

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

С уважением,
Боронин Сергей
...
Рейтинг: 0 / 0
29.10.2003, 12:05
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308675
Фотография eNose
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eNose
Участник
[не активирован]
[не одобрен]
Оттуда ( http://www.sleepycat.com/products/xml.shtml), самая первая строка в overview:

Berkeley DB XML is an application-specific native XML data manager built on Berkeley DB.

Ну и? Это обычный XML API для СОВЕРШЕННО ДРУГОГО формата.



eNose
...
Рейтинг: 0 / 0
29.10.2003, 12:11
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308678
sboronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sboronin
Гость
>А давайте не путать XMLDB:API, что является средством доступа, с форматом >хранения.
>

Никто и не путает, ведь мы сравниваем SQL-доступ с XMLDB:API доступом, т.к. это средства доступа.
Вот если бы мы сравнивали dbf и XML-файлы, тогда речь шла бы о форматах хранения.

>Изначально ведь речь шла именно о формате.
>

Если так давайте сравним DBF-файл и XML-файл, я думаю что примущество будет не за dbf :)

>А XMLDB:API можно прикрепить к чему угодно. Так же как и SQL.
>

С этим согласен, например в Nimble после того как будет реализован XMLDB:API будет реализован и SQL-доступ для облегчения миграции с SQL на XMLDB:API

С уважением,
Боронин Сергей
...
Рейтинг: 0 / 0
29.10.2003, 12:12
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308688
sboronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sboronin
Гость
2 eNose

>>Оттуда (http://www.sleepycat.com/products/xml.shtml), самая первая строка в >>overview:
>>Berkeley DB XML is an application-specific native XML data manager built on Berkeley >>DB.
>>
>Ну и? Это обычный XML API для СОВЕРШЕННО ДРУГОГО формата.
>

Ну, так никто и не говорит что база обязатльно должна представлять собой XML-файл, она предоставляет XMLDB:API который в свою черед предоставляет DOM, а что есть DOM, как не объектное представление XML? :)
При желании, DOM-объект можно сохранить как XML-файл, например для огранизации экспорта-импорта.
Формат самой базы не важен, когда есть XMLDB:API.
Так же, как вам не важен внутрений формат хранения MS SQL при SQL-доступе!

С уважением,
Боронин Сергей
...
Рейтинг: 0 / 0
29.10.2003, 12:19
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308697
Фотография eNose
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eNose
Участник
[не активирован]
[не одобрен]
Боронин Сергей!\r
Вот выдержки из Ваших постов:\r
\r
396492: Вынужден с вами не согласиться, т.к. вымирание ожидает реляционки, как морально устаревшие, а BerkleyDB и Nimble двигаются в направлении бинарных XML-based СУБД \r
\r
396599 XML это не мода - это будущее, в MS и Oracle не дураки же сидят. А ООБД свое еще возьмет, наример Cache и Fast Objects живут себе и здравствуют. \r
\r
396621 Например работу с индексами в XML-based СУБД можно доверить самой СУБД \r
\r
397469 ...Нормализованные БД на binary XML-based можно обрабатывать используя...\r
...XML гораздо легче ложится на объектную структуры, чем SQL...\r
...любая XML-база легко расширяема... \r
\r
\r
А вот из последнего: Никто и не путает, ведь мы сравниваем SQL-доступ с XMLDB:API доступом, т.к. это средства доступа. \r
\r
\r
Так о чём Вы говорите: о хранении или о доступе?\r
\r
\r
eNose
...
Рейтинг: 0 / 0
29.10.2003, 12:22
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308712
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну все же это уход в сторону - XML это одно, а движок БД, которая хранит данные на XML это другое. Это такой же движок, как и любой движок любой БД, которые имеют свои форматы хранения данных. И причем тут получается XML? Да ни при чем. Результат в нем? Дык я результат и из MS SQL верну так.
А на кой мне XML в Дельфи например? Да не нужен нифига. И зачем тогда БД на XML делать?

Не, я все же не пойму - чего в XML то так ударились? А почему не в dbf, txt еще чего там... Как универсальное средство для передачи данных между совсем разными приложениями - да, как панацея да еще БД - это уж слишком


-- Tygra's --
...
Рейтинг: 0 / 0
29.10.2003, 12:26
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308713
sboronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sboronin
Гость
2 eNose

>Так о чём Вы говорите: о хранении или о доступе?
>

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

У вас есть еще аргументы, кроме придирок к словам и формулировкам?

С уважением,
Боронин Сергей
...
Рейтинг: 0 / 0
29.10.2003, 12:27
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308720
f2f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f2f
Гость
-- Нормализованные БД на binary XML-based можно обрабатывать используя XMLDB:API без потери в скорости выборки, в отличие от реляцтонок которые теряют в производительности при нормализации, особенно если это 4НФБК или 5НФ

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

Тут требуется пояснение - это почему ?


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

Смотрю на свои базы и не могу себе представить из в виде дерева

Клиенты - отдельно
Валюта - отдельно
Договор - ну ладно можно засунуть внутрь клиента
Сделка - связана с двумя договорами (так надо). Так что тоже отдельно
Проводка - в данном случае можно засунуть внутрь сделки. Хотя здесь есть сомнения
Счет - отдельно

У меня что-то не дерево получатся, а в лучшем случае лес.
Или это мое косное мышление ?
...
Рейтинг: 0 / 0
29.10.2003, 12:31
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308736
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Дык у меня тоже дерево не получается - как складской учет в дерево запихать?

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

-- Tygra's --
...
Рейтинг: 0 / 0
29.10.2003, 12:38
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308738
Я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я
Гость
--Более естественное, древовидное представление данных

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

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

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

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

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


P.S. А насчет роли Java в Oracle вы глубоко заблуждаетесь...
...
Рейтинг: 0 / 0
29.10.2003, 12:39
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308753
Я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я
Гость
Так мы уже говорим о представлении, а не о хранении...

Тогда вообще не понимаю о чем спор, представляйте как вам удобнее
и как лучше для ваших целей...
...
Рейтинг: 0 / 0
29.10.2003, 12:48
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308812
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!
Я вот хоть убей не пойму этого выражения. Что - select * from Account inner join Details - это супер сложеный запрос что ли ? Или имеется ввиду получение данных в виде XML клиентом ? Тогда простой пример из BOL:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
SELECT
         1            tag,
        NULL        parent,
        emp_id      [emp! 1 !id],
        emp_fname   [emp! 1 !name],
        NULL        [order! 2 !date],
        NULL        [dept! 3 !name]
FROM employee
UNION ALL
SELECT
         2 ,
         1 ,
        emp_id,
        NULL,
        order_date,
        NULL
FROM employee KEY JOIN sales_order
UNION ALL
SELECT
         3 ,
         1 ,
        emp_id,
        NULL,
        NULL,
        dept_name
FROM employee e JOIN department d
   ON e.dept_id=d.dept_id
ORDER BY  3 ,  1 
FOR XML EXPLICIT

На выходе:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
<emp id= "102 " name= "Fran" >
   <dept name= "R & D" />
</emp>
<emp id= "105 " name= "Matthew" >
   <dept name= "R & D" />
</emp><emp id= "129 " name= "Philip" >
   <order date= "2000 - 07 - 24 "/>
   <order date= "2000 - 07 - 13 "/>
   <order date= "2000 - 06 - 24 "/>
   <order date= "2000 - 06 - 08 "/>
   ...
   <dept name= "Sales" />
</emp><emp id= "148 " name= "Julie" >
   <dept name= "Finance" />
</emp>

И в любой современной РСУБД этих методов работы с XML до чертиков сейчас. Вышеприведенный пример взят с ASA9 - там чего только нет - и генерация XML как угодно и по какому угодно формату и поддержка XQuery и встроенный прямо в СУБД http сервак, для которого прямо на самой ASA можно писать всякие web сервисы: HTTP, HTTPS, XML, RAW, SOAP, DISH (лично я еще не придумал, что с этим всем делать). Насколько знаю в других РСУБД тоже народ не спит и все это уже не новость.

Дык зачем же нам XMLDB ??? Я вот читал не так давно статью по поводу, что будет в новом стандарте SQL2003 (вот только ссылку найти так и не смог :( ). Там четко и ясно сказано - полностью стандартизированна поддержка хранения и обработки обьектов и XML для SQL. Сказано и зачем - чтобы SQL жил и процветал. В этой статье действительно XML называется теоретическим конкурентом SQL, поэтому чтобы сего не было, он должен быть поглощен. Что и будет скорее всего, как ранее произошло с ООБД. Причем никто особо и не против - релляционная модель математическая и строгая, SQL самодостаточный, а в кач-ве одновременно достоинства и недостатка XML называют его раскрепощенность в области описания данных. Поэтому производителям ПО легче все делать на SQL, а XML пользоваться действительно как универсальным форматом передачи данных. Высказывания не мои, а с той статьи, с XML не работал, поэтому как прочитал, так и пересказал :)
...
Рейтинг: 0 / 0
29.10.2003, 13:05
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32308913
Фотография eNose
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eNose
Участник
[не активирован]
[не одобрен]
Боронин Сергей писал:У вас есть еще аргументы, кроме придирок к словам и формулировкам?
А это не "придирки" были, а Ваши слова, где Вы восхваляли бинарные XML-based СУБД .
А как только тема стала для Вас неудобной (ну нечего там восхвалять), Вы перешли на XMLDB:API .

Так что меня обвинять не надо.

Теперь про XML: я (как и Tygra) совершенно не понимаю, зачем мне XMLDB:API в Делфи?
Мне Delphi+PL/SQL за глаза хватает.

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




eNose
...
Рейтинг: 0 / 0
29.10.2003, 13:48
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309023
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
2 sboronin
автор писал:Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!

А не продемонстрируете как на xpath получить сумму нарастающим итогом? А так же группировку с суммой. Моих знаний xpath не хватает для этого. Буду признателен.
...
Рейтинг: 0 / 0
29.10.2003, 14:39
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309568
Lepsik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lepsik
Участник
2Ermak
--Дайте четкое определение, что такое ''XML база данных".

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

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

Для конечно юзера будет просто расширение синтаксиса за счет новых функций и убирания старых.

Формально ряд запросов станет проще

--После этого будем разбираться дальше, убъет XML БД реляционные СУБД или нет.

Вряд ли.

2Glory

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

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

--А если не сможет, то присоединюсь к U-gene - какая нафиг разница каков _внутренний_ формат хранения данных в БД ???

Формат можно и не менять - только принципы работы с базой.

2eNose
--А XML файл справится с данными объемом 20 GB?

А в чем пробема ?
...
Рейтинг: 0 / 0
29.10.2003, 18:48
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309583
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
автор писал:--Если после появления всех этих "наворотов" вы мне скажите что кто-угодно по прежнему сможет запросто открыть xml файл, являющейся частью базы данных в том же Notepad, т.е. в обход ядра базы, то я просто умру от смеха.

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

Смешное то, что этот вопрос относится к индексам, триггерам и т.д. И как нотепад будет индексы читать?

-- Tygra's --
...
Рейтинг: 0 / 0
29.10.2003, 19:03
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309593
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Lepsik писал:а что тут смешного ? и почему бы и нет. ноутпад не будет зачитывать файл с диска, а будет мапить из памяти. Не вижу ничего странного или необычного.

Чего-чего ? Мапить из памяти удаленного сервера ?
...
Рейтинг: 0 / 0
29.10.2003, 19:17
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309629
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Я вот чего не понимаю... топик начался про встраиваемые СУБД, а теперь идет обсуждение XML да XMLDB:API... Это что, попытка увести обсуждение в сторону или просто незнание предмета обсуждения?.

Встраиваемая база может быть как объектная, так и реляционная. А в каком виде она уже представит свои данные и как позволит с ними работать - это другая песня, это уровень представления данных, хоть SQL, хоть XML или OQL суть параллельно.

Сходу здесь уже предлагали разные варианты встраиваемых СУБД, к примеру Fast Objects (Объектная база) и Firebird (ну и прочие указанные в топике).

Почему я раньше писал, что не сравниваемое - потому что у того же MS SQL (да и у других выделенных серверов) до черта разных прибамбасов... например, репликация. В случае встраиваемой базы я уверен, придется писать самостоятельно. Да много еще чего. С другой стороны, скорость работы встроенной базы может быть намного больше, если правильно спроектирована структура.

PS. я считаю что обсуждение собственно преимуществ и недостатков встраиваемых СУБД намного интереснее (и полезнее), чем половина написанного в треде.
...
Рейтинг: 0 / 0
29.10.2003, 20:29
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309654
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_k
Участник
что касаемо FireBird fbembeded
то плюсы которые я вижу - это отсутствие сервисов, висящих в памяти да принудительное ограничение пользователя в 1 коннект.

может быть скорость будет больше засчет однопользовательского механизма доступа, незнаю.
...
Рейтинг: 0 / 0
29.10.2003, 22:30
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309675
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
AAron

>Почему я раньше писал, что не сравниваемое - потому что у того же MS SQL (да и у других выделенных серверов) до черта разных прибамбасов... например, репликация. В случае встраиваемой базы я уверен, придется писать самостоятельно.

Не всегда. Например у сайбейза есть встраиваемый сервер, называемый ultralight, он работает с сайбейзовским же продуктом mobilink, реализующим репликации.

2 alex_k

А можно ли встроить FB в клиентское приложение, написанное на VB, VFP, PB, т.е. в приложения, не строящие независимый екзешник? Как встраиваемый сервер взаимодействует с ODBC драйвером, т.е. нужно ли конфигурировать ODBC при инсталляции и куда вообще складывается ODBC драйвер? Я не смог найти эту информацию в интернете.
...
Рейтинг: 0 / 0
30.10.2003, 00:40
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309695
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
вместо ultralight следует читать ultralite.
...
Рейтинг: 0 / 0
30.10.2003, 05:06
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309719
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Воронцов
Участник
sboronin писал:Вот неполный список преимуществ:

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

? Это приемущество? То есть способ выборки - это приемущество? Чудес не бывает - если где-нибудь что-нибудь прибыло, то где-нибудь что-нибудь обязательно убыло. Выигрывать в скорости за счёт принудительной денормализации , а точнее - отказа от нормализации как таковой я не согласен
sboronin писал:
--Меньше требуется кода для поодержки целостностид связанной с нормализацией

Да Вы что? Правда-правда? А теперь пожалуйста - с примерами. Нарисуйте мне "дерево" с вложениями одного и того же объекта в разные ветки и нарисуйте как должен выглядеть оператор изменения данного объекта.
sboronin писал:
--Более естественное, древовидное представление данных

На этот счёт Вам уже очень хорошо ответили. Древовидное представление - не самое естественное.
sboronin писал:
--Работа с DOM-объектом удобнее, чем с кучей рекордсетов, предоставляющих тот же набор данных

Вот тут готов согласиться. Иногда - удобнее. Я предпочитаю получать ОДИН рекордсет и работать с ним. Однако никто не мешает взять несколько рекордсетов и получить из них DOM объект (ADO.NET делает это со свистом). И при чём тут XML DB?
sboronin писал:
--Для получения тех же данных требуются более простые запросы, например для получения счета достаточно сделать 1 XPath-запрос к базе, при этом будет получена и шапка счета и детали счета.

То есть Вы храните "счёт". В дереве. Угу. А теперь напишите мне XPath запрос для получения товаров, поставленных в последний месяц, сумма по которым превышает среднюю за тот же месяц.
sboronin писал:
--С сохранением измененых данных тоже проблем никаких, либо сохраняется целиком DOM-объект, либо используется xpath-запрос, и хотя xpath не входит в DOM2, но он есть в XMLDB:API

А как быть с валидацией полученного в результате XPath запроса документа?
sboronin писал:
--XML гораздо легче ложится на объектную структуры, чем SQL

Приехали. Да, ложится. И там лежит. Ну и что? SQL не обязан туда ложиться - и он этого не делает. Почему все считают, что объектный подход - это серебряная пуля от всех бед?
sboronin писал:
--XML позволяет легко и естественно работать с n-мерными данными, а в "плоском" SQL для этого надо изголяться

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

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

Легко!
...
Рейтинг: 0 / 0
30.10.2003, 07:13
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309727
Ermak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ermak
Участник
Когда говорим реляционная СУБД, то преджде всего подразумеваем модель данных.
См. статью Кодда. Реляционная модель данных для больших совместно используемых банков данных

(Кроме собственно реляционной модели данных есть ещё сетевая и иерархическая (объектная ???). Мне кажется, что XML есть разновидность именно иерархической модели данных.)

2 sboronin
Давать определение XML СУБД с точки зрения " движка, предоставляющего XMLDB:API " - это несерьезно. К тому же существует такая XML СУБД как Tamino, однако на сайте в описании этого продукта ( http://www.softwareag.ru/ino/short_info.asp ) наличие XMLDB:API, там не упоминается: "В Tamino использована философия открытых СУБД, сервер содержит стандартные интерфейсы: OLE DB, DCOM, ODBC и JDBC." Попробуйте ещё раз дать определение XML базы данных.

2 Lepsik
Давать определение XML СУБД как "формально иной организации обычной реляционной базы" на мой взгляд также несерьезно.


Наличие XML надстройки не сделает реляционную СУБД - иерархической. Поймите, что "любые реляционные данные могут быть непосредственно отображены в XML, но не наоборот... XML поддерживает упорядоченное хранение данных, а реляционное представление нет."
...
Рейтинг: 0 / 0
30.10.2003, 07:35
| Ответить | Цитировать | Написать  
Встраиваемые СУБД
    #32309836
Roman Ignatiev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Roman Ignatiev
Участник
2c127 Встроенный сервер Firebird или Yaffil с клиентской стороны ничем не отличается от обычного клиента, ограничения - только одно приложение и локальный коннект без имени сервера, если указать сетевой - будет пытаться соединится с сервером и работать как обычный клиент :)
В остальном употребление ничем не отличается
...
Рейтинг: 0 / 0
30.10.2003, 09:56
| Ответить | Цитировать | Написать  
25 сообщений из 76, страница 3 из 4
  3  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Встраиваемые СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]