I'm not sure there is a good enough general case there
to warrant writing it. Most of the time once you get to
SQL you are going to use more than one table.
Factor in dependencies, one to many lookups and such and
I don't know if there is a way to do that without it being
specific to the data and application.
Now for individual tables and views on select you might
be able to make some fancy inroads. You get back a table
like:
keyfield field1 field2
=========+========+==============
Data1 f1data f2data
Data2 x1data NULL
and you want out
<dbxml>
<row>
<col>
<field>keyfield</field>
<value>Data1</value>
</col>
...
or would you expect
<dbxml>
<row>
<keyfield>Data1</keyfield>
<field1>f1data</field1>
<field2>f2data</field2>
</row>
...
The first is pretty flexible since you don't have to
deal with anything but a single DTD that describes the
general layout. The second way you have to DTD every table
so that your parser knows what to expect. And we haven't even
dealt with CDATA yet or other madness. Basically, XML is
super pimped up CSV in these cases. You use the power of
XML to express the relationships between multiple tables
and I can't even try to think about how it would be automatable
so that you could pass it straight to SQL.
Thanks, now my brain hurts again. =)
--
$you = new YOU;
honk() if $you->love(perl) |