По мне, так первостепенный вопрос - это работоспособность LEO в полном объёме, прочее же не так важно.

XML придумали враги человечества.

XML - это объекты, из которых выпили кровь.

Пособники, вредители и мазохисты.

Что касается XML, то интересно было бы узнать, поддерживается ли в Viper какая-то альтернатива текстовому формату.

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

Я видел (на zdnet вроде, или pcweek) упоминание о предложенных нескольких альтернативных бинарных форматах, но это вроде как малоизвестно и не получило широкого распространения.

Herr Developer
Victor MetelitsaНо XML-обмен между клиентами и сервером потребует преобразования этих данных в текстовый формат и обратно, что чудовищно медленно.

imho, это будет значительно меньше занимать времени, чем если будем делать сами преобразование XML<->RDBMS. Раз.

Преобразование текста в числа и обратно, сканирование и распознавание тегов всё равно будет иметь место. Вы это (при работе с текстовым XML) ничем не устраните.

Два. И почему думаете что text а не object? На клиене может быть доступен DOM-документ, а если клиент пожелаеть сделать "сереализацию" в text, то please. Но можно же работать с DOM'ом, и не знать как он устроен. Вы же не с текстом работаете...

Что за "object" имеется в виду? Напоминаю, что я не жабный, а смолточий программист (не считая БД-админства). В каком виде моя программа может отправить серверу запрос и получить от него ответ, кроме текстового XML? А как жаба? Сможет сериализовать жаба-объекты стандартными жаба-способами, или вы имеете в виду прокси на серверный DOM-объект (через прокси тоже должно тормозить, по-моему: не будет batch-вставок и т.д.).

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

[quot Victor Metelitsa]Преобразование текста в числа и обратно, сканирование и распознавание тегов всё равно будет иметь место. Вы это (при работе с текстовым XML) ничем не устраните.
[quot]
И объём теги и текстовое представление чисел чудовищно раздувают.

Herr Developer Victor Metelitsa
Преобразование текста в числа и обратно, сканирование и распознавание тегов всё равно будет иметь место. Вы это (при работе с текстовым XML) ничем не устраните.
[quot]
Большой вопрос - "передача". Если у HTTP/SOAP - то "текст", если ...

[quot Victor Metelitsa]
Что за "object" имеется в виду? Напоминаю, что я не жабный, а смолточий программист (не считая БД-админства). В каком виде моя программа может отправить серверу запрос и получить от него ответ, кроме текстового XML? А как жаба? Сможет сериализовать жаба-объекты стандартными жаба-способами, или вы имеете в виду прокси на серверный DOM-объект (через прокси тоже должно тормозить, по-моему: не будет batch-вставок и т.д.).
Под "object" имелось ввиду "object"
Ну у Вас там есть же в SmallTalk'e классы,объекты... все-таки объектый язык.


У "Нас" - да, а вот у "Вас"... это большой вопрос... ;-) почему и спрашиваю.


"Реализовать" XML можно грубо-говоря 2 классами: Node и NodeList.
Сделайте их у себя, а потом сделайте любой понравившийся serializer/deserializer хоть в текст, хот в binary, как Вам больше нравиться.


А вот никак не нравится. Да и вопрос не в этом.


Чтобы непридумывать велосипеды есть стандарт http://www.w3.org/DOM/
И потом сделайте просто клиента-сервера, который передает всю эту ботву туда-сюда. хотите текст, хотите свой бинари.
Главное чтобы "на кончах" мы могли получить теже Node,NodeList...


SAX, DOM, SOUP, UDDI и прочая хрень у Нас есть. Но стандарт - это текстовый XML. Не поддержит DB2 "мой бинари". И надо узнать, что есть у неё, и есть ли.


А как сейчас Вы работаете то с просто базой?
Есть драйвер, открываем коннекцион и
Вместо SQL, пишем XQuery. Получаем вместо RecordSeta,ResultSeta,OleDbDataReader,DB2DataReader или как у Вас => XmlDocument/XmlNodeList ( вслучае примера выше будет Node/NodeList) и все.


Это высокий уровень, а я спрашиваю про низкий. Что передаётся по сети.


И почему Вы думаете что все время надо передавать XML "открытым" текстом?
Я думаю, все зависит от реализации конкретного драйвера и поддерживаемых стандартов.

Если будет передаваться в бинарном, то это меня устраивает. Но я никогда не слышал про такие стандарты.

Herr Developer Victor Metelitsa[quot Victor Metelitsa]Преобразование текста в числа и обратно, сканирование и распознавание тегов всё равно будет иметь место. Вы это (при работе с текстовым XML) ничем не устраните.
[quot]
И объём теги и текстовое представление чисел чудовищно раздувают.
У меня есть
<Invoice..
<Item...
...
<Item

И так 100 item'oв
Да быстрее обработать 1 XML через SOAP "открытым" текстом и сделать 1 раз INSERT, пока будем делать там 101 insert'ov в одной транзакции (INVOICE,INVOICE_ITEM)

Неужто вы даже про DB2-шные CLI-функции, которые работают с массивами и могут вставить произвольное количество строк за один раз, никогда не слыхали (и на Java был эквивалент)??? И строк надо вставить не 100, а несколько десятков тысяч, по нескольку десятков полей в каждой.

не SOUP, а SOAP, конечно. Который, как говорят, на самом деле не является ни Simple, ни Object, ни Protocol.

Herr Developer Victor Metelitsa
У "Нас" - да, а вот у "Вас"... это большой вопрос... ;-) почему и спрашиваю.

Это как понимать, наезд на Java/C#

Именно! ;-)