Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase «««123

For SQL Server, XML Is One Answer Expand / Collapse
Posted Monday, October 27, 2003 12:20 PM

Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 7:59 AM
Points: 354, Visits: 67
In response to planet's reply:

In a discussion thread, a response may seem vague and ill-directed unless the thread is followed in its entirety. Moreover, nickmalik's article was written in direct counter-point to dcpeterson's. The thread there too must be read. In addition, certainly some degree of civility should be maintained; I concur. However, within the discussion threads in response to both articles, there seems to be more than a fair share of hostility directed towards the opposing view, with the viewpoint holders included, i.e., that XML is definitely bad for any want-to-be RDBMS, and potential bad for communication transfer.

However, for my thin-skinned proponents of XML's virtues, you are correct that my profane remarks have directed attention away from the meat of my comments; thus, doing myself and our respective readers a serious disservice.

So, allow me to readdress the article.

First, nickmalik states, “To make it work, XML had to be stateless, scalable, and yet easy to describe and understand. Therein lies its advantage.” I say, therein lies XML’s disadvantage.


A stateless server is one which treats each request as an independent transaction, unrelated to any previous request. This simplifies the server design because it does not need to allocate storage to deal with conversations in progress or worry about freeing it if a client dies in mid-transaction. A disadvantage is that it may be necessary to include more information in each request and this extra information will need to be interpreted by the server each time."

The concern here, as others have stated, is that XML is bloated. It is also highly dependent upon the hierarchical structure imposed upon it. It may answer one question quite nicely. However, how often does a business unit ask only a single question? This “stateless” and fixed structure nature impose quite a high resource demand and is in direct conflict with the author’s second purported “advantage.”


It is the ability of a computer application or product (hardware or software) to continue to function well when it (or its context) is changed in size or volume in order to meet a user need."

I claim XML does neither: XML does NOT scale-well with the increase of data transmission nor does it scale-well when we wish to transform it to ask new questions (context). Given the necessity to reproduce the structure imposed upon the document, whenever there is sparse data, not only do we have the encumbrance of all of those tags, we must reproduce them at every iteration, even when the structure contains very little information. Moreover, given the rigidity of the hierarchy, serving multiple users all with varying questions, a particular document quickly becomes useless to all but a very few requestors.

Perhaps as a transfer mechanism, XML could play some part—but I doubt it given its size in-scalability. However, as a means to structure, organize, and store related information, XML can neither protect, enhance, nor address the myriad unforeseen requests by the users. It fails badly for any attempt at data management. Therefore, its use as a storage mechanism is whole ill-thought.

Shall I continue? Let’s.

Our author recommends XML as a superior descriptor of related tables, far and above CSV or EDI. Hogwash. Whether a single CSV file with all of the information contained in each record, or as multiple files, one for each relation, CSV is much more efficient. Ah, but the proponents would say that it is not descriptive. But, neither is XML. You must still transmit that information between transmitter and receiver prior to understanding the intent of the information. How is XML superior in this respect?

Our author states, “Parsers for XML are free, widely available, and FAST.” So are a myriad of other “parsers” for many other formats, CSV included. Now, this is not an advocation of CSV in particular, only that XML holds no special relevance or superiority in this regard. Moreover, we must contend with the resource over-utilization given XML bloat.

Point 3: “Any system can be augmented to read and write XML.” Can we be any more general? Please; if agreed upon, any technology can be “augmented to read and write” that technology. The question is, “Why should we choose XML over other formats?”

Point 4:

“So many software vendors and application architects have seen the value of XML that an entire industry has developed around providing tools for reading, parsing, translating, routing, and managing XML documents. With so many tools available, a developer faced with the need to transfer data from one application to another would be foolish to consider spending time and effort to write components that produced or consumed data in any other format. It's just not productive to write code that someone has already written and tested, which both the developer and customer already have, and which is likely to be supported into the foreseeable future.”

Let’s all get in line. Big brother is watching. So what that there are existing tools. There are many tools out there; we have a choice. It is our responsibility to examine and DEFEND those choices.

Finally, I’ve made my arguments for not storing XML in the DBMS. Re-read them. Or, at least, refute them. Some of you have said the author is only expressing to database external recommendations for the use of XML. That XML “probably” is a bad idea for the DBMS. Oh? What did the author write?

“OK, so XML has its place. But what about inside SQL Server? Why did Microsoft add XML capabilities to their flagship RDBMS system? It was the right thing to do.”

Sounds like the DBMS has it too. Hmmm, no one advocating this position? Problem is, no one is DEFENDING this position. Can I get a witness?!

Edited by - iapetus on 10/27/2003 12:22:32 PM

Post #83820
Posted Tuesday, October 28, 2003 4:59 AM


Group: General Forum Members
Last Login: Monday, March 08, 2004 10:31 AM
Points: 181, Visits: 1
>>Moreover, nickmalik's article was written in direct counter-point to
>>dcpeterson's. The thread there too must be read

I read the original article -- I even posted a few times :)

First I should establish that I am actually in agreement with what I understand to be the main thrust of the anti-XML argument. That is that XML is inferior to RDBMS for central, long-term data storage and retrieveal. Yep, with you there. I wrote a dissertation in 2000 in which I evaluated the soon to be ratified XML standard. In the opening paragraphs of my summary I state that XML is not in anyway a replacement for the relational database. In that paper I also find in your favour that XML is not scalable. For me, using the DOM is the only way to go when using XML and this means parsing the entire document and creating the whole tree in memory -- I think that if you feel the need to use the event driven linear parsing (SAX I think it's called) except for specific and occasional functionality, you've probably gone wrong in the design.

However, I'm a bit alarmed by what I perceive as an attempt to rubbish the whole technology, simply because it is (apparantly) being set to uses for which it is clearly not fit. It's very useful and robust tool for developers in the myriad of situations where a low volume data needs to be packed up, shipped from place to place and queried. Messaging and configuration files come most readily to mind. It seems pretty obvious to me that a full featured RDBMS would be well over the top for such purposes.

OK, stateless. Yes XML is stateless and that's appropriate for the kinds of purposes that most people put it to. These days, what with the interweb et al, it's not efficient, practical or desirable to make your entire RDBMS available to anyone who might have need of it. You have to send your data out in discrete self reliant packages. XML is good for that.

I've said it before, but I'll repeat that for me the "bandwagonning" is one of XMLs strengths. Even if, unlike me, you think XML is badly devised, you could consider acknowledging the benefits of a cross-vendor, and simple standard for knocking up these ad-hoc data structures. Developers face enough problems with cross platform integration, anything that moves away from that is a blessed relief. Consider SMTP -- it looks a bit lacking in terms of authentication now, and few people would argue it's perfect for today's world. But a simple, *standard* protocol, fit for purpose, changed the way we communicate today because everyone adopted it. Ditto http/html. Whatever you think about sharky vendors trying to make a buck by adding XML to the end of their product name (and I probably share your views), please consider that the XML standard was developed and agreed upon by all the major vendors -- they agreed that there was a need for a common *non proprietary* data interchange format and that it would be good for all of them to cooperate. They found limitations with what was available and worked together on XML. Even Microsoft resisted the temptation to tinker with the crucial XSL-T specification by adding 'extended' features.

The widely criticised bloat is a price worth paying, and is in any case vastly exaggerated (ever heard of compression?), and less important as long as you are using the format for relatively small documents.

And, [desperately trying to get back on topic], because I see XML as a powerful format for developers, it makes sense that a database should support functionality to send and recieve (NOT store!!!!!!) stateless recordsets in an XML format. Converting an XML document to and from SQL statements is something that will be done in any case (I worked on software that did exactly this with SQL Server before any native XML support), so it makes sense for a database vendor to centralise the development work, provide a common interface and let everybody go home early. I agree that if the FOR XML syntax chokes the DB engine then it won't be used ... I think in the case of SQL Server, a lot more work can be done here, but I can't think of any reason why spitting out XML text streams should be particularly less efficient than generating ADO recordsets -- please le t me know if I've missed something. I've very little idea of what is planned for Yukon though -- if you know of specific examples where XML is to be prised into the nervous system of the next generation SQL Server at the expense of core functionality, let's hear them, I'll probably be right with you :)

And finally, there's XSL. Whatever you think of functional programming, there's no doubting that SQL -> (XML+XSL) is a much more pleasant way of writing data-focussed web applications than SQL -> ADO+ASP. There's lots of people writing such applications, many are microsoft customers and they are, after all, a business!

Post #83821
Posted Thursday, October 30, 2003 11:41 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, August 29, 2004 3:57 PM
Points: 50, Visits: 1
In response to iapetus and dcpeterson, and all of the other thoughful responders...

Thank you both for your well thought out responses. While I don't intellectually agree with every point you make, I commend both of you for taking the time to discuss them.

Special thanks to iapetus for thoroughly addressing the statements I made in my article. I do feel that, in the article and subsequent discussion, I've done my best to answer his or her questions.

I would be honored to work with either of you someday, if for no other good reason than to have someone around to tell me that I'm wrong

Alas, I will not convince you of my position. Hopefully, this discussion was helpful to the readers of this site.

Oh, and just for the record, I've been coding professionally for 23 years. I have a degree in computer science, a background in mathematics, and graduate-level education in database theory, set mathematics, human-computer interaction and two areas of artifical intelligence. I've coauthored two technology books, one of them on SQL Server (although it wasn't as successful as "SQL Server in 21 days,"

You see... not all XML proponents are nitwits.

With greatest respect,

Post #83822
Posted Friday, October 31, 2003 8:59 AM

Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 7:59 AM
Points: 354, Visits: 67

Thanks for all of the kind words. And, though, your response reads like a salutation, I would be very interested in any specific comments, arguments, thoughts you might have on the new features being presented in the upcoming Yukon release. SQL Mag just covered quite a few interesting "features" in the recently released November, 2003 issue. In there, right at number 3 as the most import "feature" being included with Yukon, is the XML data type.

In addition to any general comments you might have, specifically, how the inclusion of this new data type assist the DBMS with its core purpose: the insurance of consistent, persistent, flexible, quality data?

I too am glad to see that many of us are giving serious consideration and thought to the technological choices we make, not mearly going with the trend. My thanks to you and the time you have spent to ponder these questions.

Post #83823
Posted Thursday, October 21, 2004 8:26 PM

Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 16, 2013 3:09 PM
Points: 69, Visits: 194

XML is one answer, but not the ONE answer.  Be smart use it when you need it. 

It is like most other MS quickie tools, great to get started with, and a pain to get out of when you grow out of it and need something more suited for your specific 'big' project.

Wait until you hit the 4K limits around Windows and with SQL.  Then you will want to leave the data in an XML file and only store a unc or url to the xml for later use.

In multi server systems with or without DTC, XML will eventually be to bloated to use when the transactions peak, (the same is true with MS  transactional replication).  The bloat hits the network as well as the server memory resources and is difficult to recover, even if you have a top of the line system.


Clifton G. Collins III
Post #142906
Posted Thursday, October 21, 2004 8:52 PM

Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, June 21, 2011 10:03 AM
Points: 577, Visits: 102

Not just XML, but there is a whole world of interoperability opening up with Web Services, and XML (SOAP) is becoming quite popular. As a DB developer in a web dev group I've had first had experience with the power that comes with web services.  This is definitely THE "killer app" for XML.

Like it or not, XML is here to stay, and if you don't use (for religious reason's or other) you're going to miss out on a lot.


Signature is NULL
Post #142907
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse