JJ B (5/2/2008)
I certainly would rather use CSV for transfering data/communicating between databases/servers any time just because it is a million times easier and faster to create, human-read, and code-read.
So, I use CSV when I can.
BUT how would you solve the following problem without XML?
............You have to send data to another agency. The data is not only completely outside your domain, but will be put into another database tool (Sybase). Most of the data would work great for a CSV format. However, one of the fields is a Varchar(MAX) field. Data in this field ranges anywhere from 1 page to 20 pages of text, all fully punctuated with every imaginable type of character.
Could you really use CSV for this? What else would you use? I considered creating a separate text file for each row of each Varchar(MAX) field, but the programming effort of managing all those files seemed to be a lot more than the programming effort of XML, which seemed to easily handle this requirement.
What would you do? (Honest question.)
As someone who deals with this every day, I can tell you that XML is almost there in ease of use, but when it gets there, it'll be a wonderful solution to my problems.
I agree and disagree with the author here. Is it bloated compared to other ways of storing data? Yes. Is it trying to do too much, be all things to all people? Maybe. But please don't discount what it does do, because it does do it well.
My department of my company is a data shop. We get data in, analyze it, and send it out all the time. Most of the time we get flat files (CSV or other delimited), and let me tell you, finding the rogue commas in data fields to fix data import is no fun task. Also, as the above author wrote, how do you then send carriage returns, commas, pipes, etc? Big deal for us. (and don't forget cross-platform issues)
The other wonderful thing about XML is it basically forces a level of metadata documentation. If you don't think that's a a big deal, you haven't worked at a small company at the mercy of a larger company for data feeds. A large data feed shop really could care less if they lose our business, but we absolutely need theirs. So if we complain too much about needing more information, they either a) ignore it, or b) label us too much trouble and walk away. But with XML, I know that at least I'm getting field names and a relationship representation also.
I've only found one situation where I used an XML field type purposefully in an application situation (describing metadata; it worked well), but one application that maybe you haven't considered is archival. If I send a 3rd-party an XML file, I can keep an archive of it in an XML field in a table. Yes, I could just store that in a folder on the network, but this way, I can easily query it from SQL Server directly to run stats of what we've submitted. Very useful.