Disadvantages of SQLXML
-
Hello All.
I am aware of the benefits of SQLXML.
What are some of the down sides of using SQLXML in a MS SQL environment
I await your feedback
Thanks in advance.
-
Using it for what purpose? Reading in XML? Producing results as XML? Using the SQLXML ISAPI framework with template queries? Updategrams & diffgrams created with XSLT transformations of inbound XML documents?
What clients will access the server? In-house .net desktop applications, a classic ASP website, reporting applications, Access/Excel, BCP data dumps...?
Generally, the primary drawback is supporting your code. If the maintenance programmers generally know nothing about SQLXML, and it is used in only a few places, then you have made your code difficult to maintain. If there will be plenty of SQLXML throught the environment, this becomes less of an issue. Always comment well, because SQLXML never took off in the developer community as much as it could have.
In many settings, with the right implementation, the pros of SQLXML can quickly surpass the cons. Post a little more about your plans, and you might see some better insight from those who have been down those roads before.
-Eddie
Eddie Wuerch
MCM: SQL -
Eddie,
Thanks for your quick response
The choice of
Updategrams & diffgrams created with XSLT transformations of inbound XML documents would be most accurate purpose.
Currenlty using a tool generated data access layer with in-house created stored proc on sql.
I would call it an SOA environment.
Do I have to have XML mappings for Business Objects and / or table relations.
Thanks Again
-
I've used that technique - performing an XSLT translation on data to convert it to an Updategram document - several times to deal with stuffing data from several different sources into one location. I've also used it as an easy way to move a large imported recordset from Oracle (converted to simple XML by the app that pulled the data) into a table in SQL Server in a single step, without writing any loops, chopping together multiple INSERT statements, etc.
It's worked great when I was taking data files (both XML and basic text) from multiple vendors and had to get them into one location. I'd just build a new stylesheet when differently-formatted data arrived, and everything was ready: no re-writing import routines/applications/packages/whatever. For the simple text files, I'd hit them with a quick import conversion that would wrap each line with "<row>" (text data) "</row>", and wrap the whole file with "<xml>" and "</xml>" so a text file that I received that looked like this:
1,Bob's Foos,10.50,abc,nnn 2,Dave's Bars,12.75,ddd,ppp 3,Mike's Widgets,50.00,lll,sss
...would be turned into:
<xml>
<row>1,Bob's Foos,Indiana,abc,nnn</row> <row>2,Dave's Bars,Florida,ddd,ppp</row> <row>3,Mike's Widgets,New Jersey,lll,sss</row>
</xml>
...which could them be carved up line-by-line in XSLT by character position or by iterating the delimiters, and converting the whole mess into an Updategram.
<ROOT xmlns:updg="urn:schemas-microsoft-com:xml-updategram"> <updg:sync > <updg:before> </updg:before> <updg:after> <dbo.Customer CustID="1" CustName="Bob's Foos" State="Indiana" /> <dbo.Customer CustID="2" CustName="Dave's Bars" State="Florida" /> .....The drawbacks creep in on huge data sets or import files. Performing a single XSLT translation on a huge file can really consume a desktop computer or a busy server. Try a few scenarios and you'll know your limits.
You don't need XML mappings for any of the objects or relations, because each row in your updategram targets a specific table. You just need to know the relationships when you are defining the translations and line up all the names in the updategram with the target objects.
-Eddie
Eddie Wuerch
MCM: SQL
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply