relational<-->XML translation: a Python specialty absorbed by adatabase?

[John Benson]

Hi, I've been looking at the "Oracle9 i Database New Features" guide, from
which I quote:

XML Generation
In response to the challenge of generating XML in bulk from a database, XML
generation capabilities have been moved into the database and application
server
kernels and made available as built-in SQL operators. The kernel proximity
of these
operators ensures massively sustainable throughputs, enough for the largest
content repositories or the busiest exchanges.

(end quote)

I've been quaffing the XML kool-aid recently and imagining that scripting
languages like Python would be key in moving data between relational
databases and the Web by doing XML translation. From the preceding quote, it
would appear that databases might be appropriating this task to some extent.

It's pretty obvious a few XML operators added to SQL (or SQL*Plus, in the
case of Oracle) may not seriously challenge the expressiveness of Python or
Java, but they may tend to shape XML requirements in the direction of
simplicity so that the maximum can be done by the database itself.

Comments?

[rzed]

Re: relational&lt;--&gt;XML translation: a Python specialty absorbed by adatabase?


"John Benson" <jsbenson@benso nsystems.com> wrote in message
news:mailman.11 81.1075855864.1 2720.python-list@python.org ...[color=blue]
> Hi, I've been looking at the "Oracle9 i Database New Features" guide, from
> which I quote:
>
> XML Generation
> In response to the challenge of generating XML in bulk from a database,[/color]
XML[color=blue]
> generation capabilities have been moved into the database and application
> server
> kernels and made available as built-in SQL operators. The kernel proximity
> of these
> operators ensures massively sustainable throughputs, enough for the[/color]
largest[color=blue]
> content repositories or the busiest exchanges.
>
> (end quote)
>
> I've been quaffing the XML kool-aid recently and imagining that scripting
> languages like Python would be key in moving data between relational
> databases and the Web by doing XML translation. From the preceding quote,[/color]
it[color=blue]
> would appear that databases might be appropriating this task to some[/color]
extent.[color=blue]
>
> It's pretty obvious a few XML operators added to SQL (or SQL*Plus, in the
> case of Oracle) may not seriously challenge the expressiveness of Python[/color]
or[color=blue]
> Java, but they may tend to shape XML requirements in the direction of
> simplicity so that the maximum can be done by the database itself.
>
> Comments?[/color]

I've recently been working with a fairly large database with an Oracle back
end, and I've seen the difference made by moving processing to the server.
It's better. But it's not perfect.

A lot depends on the relationship between what is actually stored and the
complexity of the XML on output. If the end product consists of relatively
few elements, and the data comprising the elements corresponds pretty well
with the database, then most storage and retrieval operations would be
similar in their character to normal database tasks. That's a good thing, if
it is possible to match the data to the output closely. Adding XML
generation to the back end should make that more efficient.

If the data is complex and stored with fine granularity, then database
operations will be expensive in any case. XML in the back end will help a
little, but it would still be far more time-efficient to pull unparsed
chunks of XML data and to parse them in memory. Loading the data would also
be more efficient if it can be prechunked and stored that way. That's where
I'd think Python would shine: in the immediate pre- and post-processing
steps.

--
rzed