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 «««1112131415»»

Is XML the Answer? Expand / Collapse
Author
Message
Posted Friday, May 2, 2008 11:44 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 8:16 AM
Points: 1,035, Visits: 410
Sir Slicendice (5/2/2008)
Interesting article, but I think you (and to be fair, lots of others) have missed one of the most valuable benefits of XML:

The standardized hierarchical nature makes it very, very easy to transfer set-oriented data without having to invent and process ad-hoc keying systems.

To store or transfer set-oriented data that spans more than one table, you need a keying system; in XML, hierarchial arrangement eliminates the need for any keying when the schema can be presented as a DAG. This is a vitally important benefit, and likely the single largest reason XML has been widely adopted -- yet it is somehow almost always overlooked!

Set theory as being superior somehow superior to graph theory? Methinks someone needs a bit more exposure to these subjucts to understand what they said. And you really need to do more thinking about the OO-graph theory criticism, versus the relational set theory accolade....

As for MISMO, as a former member of a MISMO committee (one of many, both committees and members), I feel your pain! But a key thing to keep in mind about MISMO and all other XML standards: these standards embody full data schemas for their respective businesses, including data relationship, coding, and validation rules, as well as integrity constraints. The alternative to an XML schema would be either:
1) flatfile definitions with a shelf full of written documentation
2) DDL for a full relational database



Just a couple of things...

I never said that Predicate logic and set therory were inherently superior to graph theory, that would be a very ignorant thing to say... There isn't a question that they have proven superior methods for developing data management systems because they are vastly simpler to implement and manage, while being sufficient for the task.

I'm not unaware that XML does have some benefits conferred by its hierarchical nature and being accepted as a standard, but I do maintain that the costs GENERALLY outweigh the benefits, particularly when it comes to data management.



/*****************

If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek



*****************/
Post #494450
Posted Friday, May 2, 2008 11:50 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Friday, April 4, 2014 4:40 PM
Points: 751, Visits: 917
I partially agree with you. XML is definitely highly over used and sold to do far more than it really can. With that said, it certain does have certain niches as a standard way for certain types of genuinely hierarchical data. I think that in most cases XML does not belong in a database, but there are a few exceptions even there and plenty of places outside of relational databases that are useful.

---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
Post #494454
Posted Friday, May 2, 2008 12:14 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 2:47 PM
Points: 132, Visits: 114
"Is there an Object-oriented database that persists methods within each object? (loaded question)"

Yes. Oracle.

"The alternative to an XML schema would be either:
1) flatfile definitions with a shelf full of written documentation
2) DDL for a full relational database"

You say that like it's a bad thing! :P

Seriously, there's no substitute for clearly written English (or other human) language documentation.

And I find both 1 and 2 much easier to read than a DTD or (horrors!) an XSD.
Post #494466
Posted Friday, May 2, 2008 12:16 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 2:47 PM
Points: 132, Visits: 114
"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."

The first thing would be to create two transmissions by putting that huge field into a separate file.

Second, if that's not possible, the ` (grave) character, by itself, has no lexical value in any language. It's 7 bit ASCII, which makes it the ideal delimiter.
Post #494470
Posted Friday, May 2, 2008 12:21 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, April 18, 2011 12:46 PM
Points: 10, Visits: 47
The article and the discussion is really interesting.
I am not expert on this.
Silly Question : When we have just flat file instead XML, Don't we stuck with Deliminator like comma or # or any character.. Or fixed length, We should be very cautious during parsing. XML avoid that am i right? Please Answer
Post #494475
Posted Friday, May 2, 2008 12:23 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, August 28, 2014 1:09 PM
Points: 63, Visits: 663
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.
Post #494478
Posted Friday, May 2, 2008 12:29 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 15, 2014 3:43 PM
Points: 266, Visits: 2,593
Stephan: Thanks for the reply. If I understand you correctly, you are suggesting that I could create a delimited text file, but instead of using a comma, I could use the grave character? Or maybe you are saying this: the narrative should be in its own file where each narrative record/table row is separated by the grave character?

I've never heard of the grave character. I'm going to look into it. I'm sure my peers in the other agency would appreciate an alternative to reading my XML files.

My biggest concern for using the grave technique would be: I know that most database products know how to easily read CSV files. Similarly, there are standard methods for reading XML files, even if it is a pain. Would a database product have built-in (or at least easy coding) support for reading a file where "rows" are separated by the grave character? If lots of special code had to be written to read grave files, I'm not sure the grave solution would any better than the XML files.

Just some thoughts. Thanks for your thought.
Post #494486
Posted Friday, May 2, 2008 1:04 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 2:47 PM
Points: 132, Visits: 114
"If I understand you correctly, you are suggesting that I could create a delimited text file, but instead of using a comma, I could use the grave character? "

Yes.

"Or maybe you are saying this: the narrative should be in its own file where each narrative record/table row is separated by the grave character?"

Not quite. Maybe the narrative could be in a file structured like PK`Narrative?

"I've never heard of the grave character. I'm going to look into it. I'm sure my peers in the other agency would appreciate an alternative to reading my XML files."

Sure. It's the lowercase key next to the "1" on US keyboards (other keyboards, YMMV)

"My biggest concern for using the grave technique would be: I know that most database products know how to easily read CSV files."

Most DB products will let you select your own delimiter. Just select ` instead of , ; | etc.

"Similarly, there are standard methods for reading XML files, even if it is a pain. Would a database product have built-in (or at least easy coding) support for reading a file where "rows" are separated by the grave character? If lots of special code had to be written to read grave files, I'm not sure the grave solution would any better than the XML files."

If it's at all decent, then yes.
Post #494505
Posted Friday, May 2, 2008 1:32 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 15, 2014 3:43 PM
Points: 266, Visits: 2,593
Stephen: Thanks for the additional clarification. That helps.
Post #494515
Posted Friday, May 2, 2008 3:44 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:05 AM
Points: 2,842, Visits: 3,875
From my experience, XML is more or less document-centric.
It allows easy validation and "ETL" from a document using XSLT.

If a "document" is only rows & columns, then XML is probably overkill.
But if it is hierarchical or at least more complex than rows & columns, it
can be beneficial.

I also think that the main benefit is not in the database, it is in the
handling of the data within an application (ever tried parsing a complex
text file?).

Extending XML to the database is just a natural evolution.
Why not store such documents directly in the database? You need to
consider performance, that's true, but is this really the key factor for
your specific application? It always depends.

What I don't consider a use of XML is data exchange in the form of "batch" ETL
from sytem to system. In contrast, for "document centric" ETL I would consider
the use of XML but considering doesn't mean also using it in the end.



Best Regards,
Chris Büttner
Post #494570
« Prev Topic | Next Topic »

Add to briefcase «««1112131415»»

Permissions Expand / Collapse