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 12345»»»

Is XML the Answer? Expand / Collapse
Author
Message
Posted Sunday, October 5, 2003 12:00 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
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/dpeterson/isxmltheanswer.asp


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

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 #16965
Posted Tuesday, October 7, 2003 2:06 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 1:07 AM
Points: 2,901, Visits: 1,805
Nice to see someone playing devil's advocate.

I'm not sure that I totally agree although I have very limited XML exposure.

My understanding is that the rules about what an XML file can and cannot contain can be restricted via a schema. Provided you don't change the rules within a schema then you are OK. The nearest programming equivalent of "Don't change your schema" is "Don't change your class interfaces".

Because an XML document is usually a text file it can be read by almost any OS. Yes, other formats are faster but that limits cross platform compatibility.

XML is designed to be used over the web. My understanding is also that XML is an attempt to separate web content from web presentation. If the document is dictated by the Schema then I could take your XML document and apply an XSLT to it to display your document in a number of completely different layouts.

I have to say that initially I was underwhelmed by XML. I thought it looked like the web equivalent of a COBOL data-division!

Hierarchal data is a pain to manage and administer but it's main advantage is speed. I've read that there are people out there who have databases so large that RDBMS technology struggles to perform all the overnight processing.

Granted that for most people the RDBMS is the answer to a lot of questions but there are always people who need a better mouse trap!

I'm nost saying that XML and XML databases are the answer but XML does have its uses.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #82189
Posted Tuesday, October 7, 2003 2:50 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, March 15, 2005 2:29 AM
Points: 76, Visits: 1
I think you have missed one of the main benefits of XML. Its not an ideal storage medium, its not a lean storage medium either...

Where it does excel is in transportability. We have a very major data store for the travel industry which we offer to customers via a XML interface. The reason we use an XML interface is that it is the only way we could easily distribute the content in a standard format across many channels.

The data is a complex relational set and could not be distributed (In real time) any other way. We couldn't pass a series of CSV files for the related data, XML was the only way to go.

XML is fantastic at what it does and has opened up a whole new area of data management and distribution for many companies, system can be developed that were just not feasible before.

We do however store and manage our data in a fully relational SQL database.


Dan




Post #82190
Posted Tuesday, October 7, 2003 3:18 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Monday, March 8, 2004 10:31 AM
Points: 181, Visits: 1
I think David has nailed the key point here.

>Because an XML document is usually a text file it can be read by almost any OS.
>>Yes, other formats are faster but that limits cross platform compatibility.

XML has been offered up a standard format for presenting data. This being the case, the most important decider of its success is that the standard is widely -- dare I hope universally - adopted. In the case of XML, the major players have got behind this particular standard and, as far as I am aware, co-operated in a really positive way. In fact, it's about the only thing I see Microsoft/IBM and Sun all in agreement about. Microsoft gave support to the standards effort, releasing good neta parsers and documentation for free before the standard was ratified -- and then immediately made their release parsers compliant to the final published W3C standard -- removing some proprietary gizmos they had put in there before the standard was fixed.

I use XML a lot and I like it. It's excellent for messaging, I am continually surprised at how powerful and versatile XSL-T is, and I consider it a very useful tool for a wide range of development problems. Sometimes there is an elegance you can't get in procedural programming.

Human readibility of data documents *is* useful when you are a developer, even if the end-consumer (a computer) doesn't care, someone still has to make and debug the thing. The repeated tags in an XML document lend themselves very well to current compression techniques, and through schemas we have a *standard* way of validating data documents/messages that we don't have for flatfiles.

Sure XML is just not useful for high volume/long term storage and retrieval -- but we have databases for that. It's a bit like writing off SQL Server because the games aren't as good as on the playstation.





Post #82191
Posted Tuesday, October 7, 2003 3:37 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, July 24, 2009 2:51 AM
Points: 2, Visits: 4
My role in the company I work for is that of both software engineer and DBA. That being the case, I had mixed feelings about the article - applauding some of the points made, wondering whether the wider issue was missed with others.

One of the biggest struggles I have with the developers I work with is to get them to think relationally first, object oriented second. Similarly, because of the hierarchic nature of XML, I have the same struggle! I personally do not feel you can get the richness in meaning availble to RDBMSs in XML. Anybody who has tried mapping a many-to-many relationship in XML knows just what I mean. That, and I have a firm belief that good software flows naturally out of a good database design.

So using XML to hack the relational model is b-a-d. However, using XML to map to a relational model is not necessarily evil.

The argument that if tags change that everything breaks is true, however, why would the tags change? The same is true if you rename a field within a table or change its datatype. You just don't do it, or at least not without significant impact analysis.

But there are many advantages to XML too. First and foremost, it's a standard. It has its faults (as pointed out in the article) but nonetheless, it is a standard. Developers have no need to reinvent the wheel on each project - the same toolset can be used across all projects to carry out the most standard of tasks. Standardised and generally bug-free too. Also, XML data feeds facilitate more meaningful code. You're getting the product's colour in your code rather than the first item in a CSV list. Anything that allows people to write precise and concise software that *works* is a gift.

There is the argument that data processing should be distinct from data transport. That's generally because firstly we humans think better in terms of distinct layers, plus data transport rarely has problems, in comparison to data processing at least. But the fact is that no database exists in isolation. If one part of the system fails, the system is seen to fail as a whole, and the fault you refer to should be shared by all - not just the database guys, the programmers or their respective methodologies. It's the business failure that hurts, not the technical failure.

I wonder why people do not worry about ADO or (especially) ADO.NET as they do XML? Both means require the transport of metadata as well the data itself, yet this is usually fine? Maybe if there were something more mystic about XML than just plain text people would have more belief in its capabilties.

I had to smile at the "ignorance" claim, simply because I think we all know just what the author means! Why the hell do we need an XML data service on a biscuit tin anyway?
I think the additions of "stupidity" and "greed" don't give a balanced representation of the vendors' position though. There are genuine benefits to vendors in terms of widening hardware and software capabilities whilst reducing implementation overheads. Take, for example, set-top boxes. These are capable of using the same ROM-based XML APIs for multiple purposes, using one communications protocol (HTTP) without the need to implement ODBC connectivity. This allows manufacturers to fit more data-rich services in the same storage space, minimising the quantity of service-specific data manipulation routines, and without storing drivers for every concievable database out there.

I think the conclusion I draw is that XML data services using an RDBMS as a backend have their places and uses. They do not fulfil every need there's ever been, so no, don't believe the marketing hype. But don't dismiss it either - you could find yourself talking yourself out of a valid and efficient wider system, given the right context.




Post #82192
Posted Tuesday, October 7, 2003 4:05 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, Visits: 7
Hats off and a standing ovation to Don! You are so right in everything you write in the article. Some comments to the other comments you have received so far:

quote:

Hierarchal data is a pain to manage and administer but it's main advantage is speed. I've read that there are people out there who have databases so large that RDBMS technology struggles to perform all the overnight processing.



First of all, the primary function of a database is not speed, but integrity. Second, the relational model can not be blaimed for inefficient implementations of it. Performance is a determined by the physical implementation of a database, the relational model is purely logical.

quote:

Because an XML document is usually a text file it can be read by almost any OS. Yes, other formats are faster but that limits cross platform compatibility.



Why would this limit cross platform compatibility? Any platform can read a text file, no matter how the contents of it is formatted. XML in itself have absolutely no advantage to say a csv-file, it is the fact that it has become a de-facto standard that makes people choose xml over any other formatting. But, as Don points out in his article, it is definitely not an entirely wise choice, it has several major drawbacks. But this is just speaking about xml as a format for transferring data. Regarding data management and using xml as a data storage, there is absolutely no advantage at all over a relational database.

quote:

The data is a complex relational set and could not be distributed (In real time) any other way. We couldn't pass a series of CSV files for the related data, XML was the only way to go.



How can a hierarchical xml file store complex relational sets?

quote:

I think the conclusion I draw is that XML data services using an RDBMS as a backend have their places and uses.



Yes, you are right, I wouldn't argue that this is entirely wrong, if you stay with using xml as a data transport between applications. But I think that even though Don (and I agree with him fully) does not believe xml to be the definitive answer, what he is really saying in this article (especially since it is actually published at a SQL Server specific site) is that xml has no place inside SQL Server. And that is a very important message! We as developers and DBAs can do our part by not using these features and by continuing to request more important features and functionality, especially a better implementation of the relational model.

I'll finish off by seconding the book recommandtions in the article. I guarantee you, when you've read these books you will not continue argumenting for xml.

--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
http://www.sql.nu




--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
Post #82193
Posted Tuesday, October 7, 2003 4:35 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, March 15, 2005 2:29 AM
Points: 76, Visits: 1
quote:

How can a hierarchical xml file store complex relational sets?



Because it is doing what XML is best at... storing a single or selection of records and not an entire database. A hierarchical xml file lends itself very well to a correctly structured relational database.

On a one level, one of our outputs relates data across 5-6 tables with various join types. The output of this is fantastic via XML, customer query our data via a web service (Which can also take the query via XML or traditional query string items) and we return the matching record(s) via a very easy to use XML document.

There would be no easy way of doing this output without XML.




Post #82194
Posted Tuesday, October 7, 2003 4:45 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 1:18 AM
Points: 5,956, Visits: 285
quote:

quote:

Hierarchal data is a pain to manage and administer but it's main advantage is speed. I've read that there are people out there who have databases so large that RDBMS technology struggles to perform all the overnight processing.



First of all, the primary function of a database is not speed, but integrity. Second, the relational model can not be blaimed for inefficient implementations of it. Performance is a determined by the physical implementation of a database, the relational model is purely logical.


I do agree with that.
The best RDBMS system struggles with poorly implemented db design and application design. And that's not a lack of the RDBMS itself.

The relational model is NOT designed to handle hierarchies after all. In fact, it is the successor of the hierarchical model. Designed to get rid of the limitations of the hierarchical database model. It might be true, that the network model or the hierarchical model are faster than the relational, but as Chris has said that is not main focus of a relational db.

As for XML, a classical case of 'It depends...and time will tell'
IMHO, I don't use it, because I see no need to.

Frank
http://www.insidesql.de


--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/
Post #82195
Posted Tuesday, October 7, 2003 5:23 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Monday, March 8, 2004 10:31 AM
Points: 181, Visits: 1
>>Any platform can read a text file, no matter how the contents of it is formatted.

true. but wouldn't it be great if there was a standard cross platform API for validating and querying such data from applications?

>>XML in itself have absolutely no advantage to say a csv-file,

see above.

>>it is the fact that it has become a de-facto standard that makes
>>people choose xml over any other formatting.

You say that like it's not important --- it is the absolute clincher. HTML may not be perfect, but simply by gaining a critical mass of support it has completely revolutionised one type of client-server application (publishing for human readers). At it's simplest level XML can be seen as an attempt to standardise (edit) an interface onto (/edit) CSV files. This is an essential foundation on which we can build higher level standards of inter-computer messaging.

Add to that the fact that, with XSL-T, a new generation of developers are considering the benefits of functional programming and I think it's worth standing up for :)

>>what he is really saying in this article (especially since it is actually published at a SQL
>> Server specific site) is that xml has no place inside SQL Server.

Well, half the article is a (very flawed, in my opinion) attack on XML in the large. Only in the second half does it home in on SQL Server. I don't see anyone in this thread supporting the idea of storing data as native XML within an RDBMS -- and to be honest, I've never heard of support for this made anywhere else.

However, outputting query results direct to XML seems very sensible and it's something I use often. I think all the major vendors now support it -- to a certain extent this maybe just bandwagonning, but as Frank says, time will tell.





Edited by - planet115 on 10/07/2003 05:43:53 AM



Post #82196
Posted Tuesday, October 7, 2003 5:39 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 10:52 AM
Points: 295, Visits: 277
It is very nice to see a viewpoint that is different from what all the pundits are touting. This is a very good article but it does miss a couple points.

XML is more transportable because everyone doesn't have to agree on a single way to structure the data. If I get three XML feeds from three different sources and they contain the same data in a different format I can use XSLT to restructure them into the format my application expects. It's easier and faster (read as: more cost effective) to write a transformation when we get a new data feed than it is to write a bunch of procedural code and recompile my application.

In regard to the "flawed" OO paradigm, the real flaw is the people that don't know how to convert an object model to a data model. The people designing databases that can't fit an OO application are the same ones that can't design a DB for a procedural app. They are also the ones that blame the database server when something doesn't work.

OO and relational work perfectly well together. Use OO code to get the data in a structured format and then put it in a relational database in an appropriate format. You then have good data that can be used in the OO world and is great for set-based reporting.

BTW, OO is certainly not the end-all be-all of software development. Procedural programming is far from dead and appropriate in many areas (Event-driven GUIs for example).

The Information Technology arena has no room for extremists. Use the right paradigm/methodology/tool for the job.


Bryant E. Byrd, MCDBA
Sr. SQL Server DBA/Systems Analyst
Intellithought, Inc.
bbyrd@intellithought.com


Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #82197
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse