> 1) Do your customers even know about SQL/XML? Remarkably little has been
> written about it on the Web or elsewhere.
On the whole, probably not, but I'm working on that a few students at
a time. We cover this in our SQL Server 2005 classes a bit so that a.)
folks are aware that SQL/XML exists and b.) what MS does is different.
> 2) Does anybody know how widely SQL/XML functionality is used in the
> databases that do support it (DB2, Oracle, Sybase, and DataDirect's JDBC
> driver)? I would certainly use it if I had one of those databases, but
> the few real-world customers I meet still seem to be writing custom code
> to construct XML
Last year I gave a number of talks around the US and this was one of
the questions I'd ask. Most of these talks were pretty well attended,
so by that measure, there's a fair amount of interest in the
technology. A good portion of the folks attending did store XML in
tables, but they really weren't doing much at the storage engine level
with that it. I think some folks are starting to want to use XML more
at the engine level, however, so that's where SQL Server's XML type
comes into play. Frankly, there's not much point using that datatype
unless your actually going to use the features like schema-binding,
XQuery and indexing that go with it.
.
> 3) In all fairness, FOR SELECT EXPLICIT is only marginally less ugly
> than SQL/XML, and neither comes close to XQuery, which is postively fun
> to write.
There's so little reason to write explicit queries with SQL Server
2005 anyway. Use FOR XML PATH as a direct and "less code, more
obvious" solution. As to XQuery, I really believe that most SQL Server
2005 will choose to write XPath expressions first and resort to the
FLWOR syntax when the run into a brick wall. That's probably because
of the folks using the feature today are middleware or client
developers.
Thank You,
Kent Tegels
Database Curriculum Lead
Blog: http://staff.develop.com/ktegels
DevelopMentor -- Advanced Training for Professional Software Developers
|
