Новость приятная, особенно поддержка linux, вот только...
вот только у меня она отказалась работать под этим самым linux :(
при создании бд, прога отжирает всю память,
и либо ее вовремя стоит отрубать, либо системе приходит.. непреодолимое желание перегрузиться :/

Ну, поехали...

Басы: А мне это не надо, значит, фтоооооопкууууу....
Теноры: А что такое XMэээээээLллль
Дисканты: А все равно рулит МайЭскуээээээээль!
Фальцеты: !@#$%^&*!

LOL!

maxcom, прикрути уже спелл-чекер, а? ;-) Ну, или расскажи, что означает "выпушивать" :-)))

Что вы делаете с этим ужасным паравозом, который отжирает всю память?
Неужели он работает быстрее, чем fgrep? Не верю (c).

> Что вы делаете с этим ужасным паравозом, который отжирает всю память?

Ну например, пользователь говорит, а покажите мне книги по Linux выпу_щ_енные после 2003 года с авторами в количестве более двух человек; издательства о'рейли, новелл пресс и самс; чтоб страниц было не менее 500 и... на всякий случай не стоит мне показывать книги среди которых есть автор Phedorchuk ;). Да, и упорядочте их мне по цене.

Да легко! 1 запрос на XQuery, а сколько мучаться fgrepoм? Right tool, for right job, верно? ;)

вообще то для этого eXist уже сто лет как существует

><xml>

> <sucks>

> <compared>

> <to>

> <s-expressions/>

> </to>

> </compared>

> </sucks>

></xml>

>(because it's (and (stupid verbose)))

<moron>

<fucking>

<are>

<you/>

</are>

</fucking>

</moron>

('cause steam locomotive is gone...)

Написаное на яве и написаное на c++ в общем две громадные разницы

> Да легко! 1 запрос на XQuery, а сколько мучаться fgrepoм? Right tool, for right job, верно? ;)

Про "right tool" в общем и целом верно, а xml по любому sucks.
И БД евоные тоже сакс ;) И задача решается много проще без него.
Есть гора информации. Есть её каталог. Нормальный, без извращений.
Вообще какой идиот придумал пихать xml во все дыры? Ну, структурирована
информация. Вопрос: для кого? И человеку её читать непросто, и машины
загибаются ;) Во придумали игрушку!

Ну все пока развивается и XML еще не имеет такой истории и развития как реляционные данные (РД), это отчасти объясняет тормознутость и монструозность ;) Вообще, мощь XML в том, что в отличии от реляционных данных он являет нерегулярным и непредсказуемым. Да, РБД могут представлять такую структуру, НО поиск объектов на неизвестной глубине очень сложен. XML может описывать сам себя, для РД нужно создать метаданные (опять излишнее усложнение). Результат запроса XML может состоять из разнородной последовательности, каждый элемент может иметь свой тип, свои атрибуты. Это РБД себе ну никак не могут позволить. Ну и т.п.

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

> XML еще не имеет такой истории и развития как реляционные данные (РД)

Да уж добрых десять лет. Мало?

> XML может описывать сам себя

Во как... Мысли ловит? Хочу такой XML.

объясните на пальцах
даны терабайты данных.
Это значит - миллионы файлов, да? (ну не один же xml:)
как индексируем? (btree? hash?)
где этот индекс? я предполагаю, что тот сишный код - это имплементация того индекса, да?
теперь _что_ индексируем? и таги и аттрибуты, я правильно понимаю?
(ведь без индекса мы будем проходить всё подряд, делая сравнения и парся каждый файл).

Если выше я прав, то теперь вопрос:
если я имею в линейное (или логарифмическое) время _любую_ структуру в памяти по любому набору ключей, _что_ мне даёт именно xml?

Если у тебя ещё нет геморроя, то его и даёт ;)

>Да уж добрых десять лет. Мало?

Ты с какой лушы упал? Стандарт XML 1.0 в 1998году принят, всего 6 лет

А до стандарта несколько лет висел драфт, правильно? Ну, хорошо, пусть
7 лет.

Офигенный срок 7 лет, ага. РД насчитывают уже без малого 30 лет. Сколько ушло времени, чтоб написать субд хоть как-то быстро работающие. Да и то, додумались, к концу жизни использовать sqlite, ага, все остальное же тормозит. А тож, ведь вокруг куча придурков, кто не может использовать РД _правильно_. Вот и XML тоже предстоит пройти путь нелегкий, оптимизироваться и потом найти своих придурков, которые будут использовать его в качестве языка написания ядра новой ОС.

Ну да, есть eXist. А еще Xindiche, Ozone, Tamino и добрых три десятка других. Разве это чем-то мешает? Зато у Sedna есть такие преимущества, как native xml storage и Scheme api, а теперь еще и лицензия Apache.

>Ну например, пользователь говорит, а покажите мне книги по Linux выпу_щ_енные после 2003 года с авторами в количестве более двух человек; издательства о'рейли, новелл пресс и самс; чтоб страниц было не менее 500 и... на всякий случай не стоит мне показывать книги среди которых есть автор Phedorchuk ;). Да, и упорядочте их мне по цене.

Не вогнал что-то я, чем вот так хуже?...

SELECT

* FROM Books B, Press P, Autors A

WHERE

B.Autors_Id = A.Autors_Id

AND B.Press_Id = P.Press_Id

AND Books.Date_Out > '2003-01-01'

AND P.Name IN ('О''Рейли', 'Новелл ......) AND A.Name <> 'Phedorchuk'

AND B.PageCount > 500

............

AND B.Name LIKE %Linux%

ORDER BY B.Price

Примерно, конечно...

Смущает что нет условия "с авторами в количестве более двух человек", оно тут одно из ключевых. Чтобы сделать это в РД, ой как надо подумать над структурой таблиц. А если это условие возникло после сдачи проекта и его никто не предусматривал, а сервис таки понадобилось расширить. Придется либо составлять несколько запросов, либо переделывать структуру таблиц. XML от этого защищен своей неоднородностью и гибкостью. XQuery+XPath также более мощная связка чем SQL, больше типов, мягкая и жесткая типизация, ратификация схемой и прочее.

Элементарный вложенный подзапрос спасет отца русской демократии. Не с MySQL конечно :)

> Элементарный вложенный подзапрос спасет отца русской демократии. Не с MySQL конечно :)

Не, ну на дворе уже 3-е тысячелетие. Оно таки с 4.1 уже может, мейджик )

> додумались, к концу жизни использовать sqlite, ага, все остальное же тормозит.

А потому что нефиг было слезать с clipper'a и foxpro. Они были вершиной
мысли в БД-строении. И ничего лучше до сих пор не придумано. Просто
каждое новое поколение программеров плодит свою очередную бередовую,
но шибко "передовую" технологию. SQL - это был шаг назад. XML - два.
И не подумайте, что вперёд ;) sqlite - не от нефиг делать появилась.
Жизнь заставила. Очень хреновая жизнь.

> А потому что нефиг было слезать с clipper'a и foxpro.

А может ну их эти новые технологии, ДОС, да 640К рулят, так? ))

Не смешно совсем. Скорее грустно. 30 лет потрачено на тупиковую технологию.

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

> Если выше я прав, то теперь вопрос: если я имею в линейное (или логарифмическое) время _любую_ структуру в памяти по любому набору ключей, _что_ мне даёт именно xml?

Просто XML &#8211; это язык для _структурированного_ хранения _документов_, но НИКАК не данных, хранящихся обычно в соответствующих БАЗАХ ДАННЫХ. И никто из разработчиков XML не позиционировал его как замену Oracle, MySQL etc

> А потому что нефиг было слезать с clipper'a и foxpro.

Это хлипыр и лиса то вершины мысли? Это потому, что кроме хлиппыра ты "больше ничего не умеешь"?