xml ignorant

[Rut]

I'm looking for a crash course in the use of xml. I am a programmer of
mostly client-server type apps hitting against sql server. I don't
program web related apps at all. I've taken classes in xml but as of
yet see a real use for it in my day to day programming.

Where would it be useful/beneficial in a client-server arena?

When would it be advantagous to store data in xml format in a database
(sql 2005)?

At what threshold (record size?) does xml become unreasonable slow to
deal with?


It just doesn't seem practical to move large numbers of records around
in xml format. Just too slow. Or am I missing something?

thanks,

XML DEPRIVED

 

[cr88192]

I'm looking for a crash course in the use of xml. I am a programmer of
mostly client-server type apps hitting against sql server. I don't
program web related apps at all. I've taken classes in xml but as of
yet see a real use for it in my day to day programming.

well, uses, if they exist, may just pop up.
I am just answering based on my general oppinions, and thus have little
weight.

if one allready has an xml parser in place, they may as well use it (vs.
comming up with or using something else).

Where would it be useful/beneficial in a client-server arena?

openness, mostly.
flexibility may also be a factor, and some protocols have shown this (eg:
xmpp as a good example).
(one may argue that other formats can be made similarly flexible, but often
they are not).

When would it be advantagous to store data in xml format in a database
(sql 2005)?

err, dunno here...

presumably a dbms would internally use a more optimized format (binary
records and b-trees come to mind). I guess for a small database it could be
ok to use xml.

At what threshold (record size?) does xml become unreasonable slow to
deal with?

can't really answer objectively, and this would likely depend a lot on the
parser.

imo, I like xml for small data (maybe up to a few hundred kB), much more and
I think something else seems needed.
imo, a signifigant problem with xml is that (within normal constraints), one
can't quite treat it like a format like riff (directly
reading/searching/skipping over the contents of a file without having to
parse first).

It just doesn't seem practical to move large numbers of records around
in xml format. Just too slow. Or am I missing something?

what is "slow" is hard to quantify exactly, and what is too big is similar.
binary formats can be both slower and larger than xml, or can be much
smaller and faster (but often far less flexibile).

similarly, xml is not "that" ineffiecent (tokenization, number parsing, ...)
is not necissarily all that signifigant. similar goes for size, xml can be
both larger or smaller than comprable "structured data" approaches.

the main case where binary formats win is either specialized encodings or
raw data, but these type of formats are often fairly closed and inflexible.


it depends a lot on what one wants I guess.


I may just be a stupid newbie/troll here...

 

[Philippe Poulard]

use the tool that suits your problem : if you have to deal with huge
amount of datas, use an xml native database ; xnd can store xml datas
and provides quick datas access ; they are like rdbms : there is a
logical view ( table/infoset ), a query language ( sql/xpath-xquery ),
and other features ( acid... )

have a look at tamino or xyleme
--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[cr88192]

use the tool that suits your problem : if you have to deal with huge
amount of datas, use an xml native database ; xnd can store xml datas and
provides quick datas access ; they are like rdbms : there is a logical
view ( table/infoset ), a query language ( sql/xpath-xquery ), and other
features ( acid... )

have a look at tamino or xyleme

misc question:
do such databases use textual xml, some form of binary xml, ... ?

for xyleme at least, what info I could find suggests uses of some sort of
"index" (dunno much more). otherwise, it doesn't sound that much like a
conventional database.