Is XML the Answer?
-
The difference is that an entire system would stop functioning correctly if it couldn't cope with the rollover to a new century, where as if you don't use XML....so what?
-
I have read the article and most of the posts on this topic. Having been around the industry for sometime I find myself challenging my will not to agree with XML being inherently "bad". The article brings out very valid points to the short comings of the XML technology. I still have to be the romantic here. I have used XML extensively over the past few years building databases, applications and infrastructure with SQL Server, BizTalk, MSMQ, SQLXML and .NET. I have found it has its arena. I for one have never even considered storing XML in a database or using XML for data storage for anything other than remote users visiting clients or temporary transaction processing. It does not mean I will not consider it in the future. I think this may have become a trend in the industry generated by exceptional marketing, but if do diligence is executed for each facet of your venture then the place for XML will be utilized acceptably. I guess what I am trying to say is, be mindful of what you design/architect. Just because the ability to choose a conduit is accessible does not authenticate the direction will be plain sailing the whole way. Research and Validate
My 2 cents,
T
-
The author is obviously not seeing the big picture. Who said XML was supposed to be stored in the database? Of course that makes absolutely no sense what so ever. The whole point of XML is universal data exchange. XML should be generated by an application (which SQL Server can do with FOR XML) or parsed by an application before it is loaded into a relational database.
-
NOTE: when I say comma delimited, I mean any one character field delimiter, some use pipes, tildes, tabs, etc.)
I loved the article, Don. You presented many valid points and those that are opposing your points are wrong. For example, saying that you don't need a predetermined format for XML or that you can put multiple record types in XML, but you can't in a comma delimited file are wrong statements. You can put multiple record types into a comma delimited file, if you need or want to send only one file. Also, ALL data transfers require an agreed upon format between the source and destination. Just because someone has taken the time to lay these out in XML, does not mean that there were not standards before that for comma delimited files. XML is a big fat pig that consumes substantial resources for no real benefit. Any benefits that are stated for XML can be quickly countered, including XSLT. Again, someone just sat down and wrote a standard and a tool. This does not mean that the exact same thing couldn't have been done for standard delimited files and in fact there were several tools that did just that.
Additionally, to support a pig by saying that feed is getting cheaper is ridiculous ("Bandwidth will get cheaper as will storage space"). What kills database performance is non-database professionals designing databases. Developers (programmers) are some of the worst database designers, because they think iteratively, whereas a good data model and well written queries are based on mathematical set theory. Here is an example that I ran into about a year ago. A company had a query that ran fine until it encountered a real data set and then there was one query that would run for more than 9 days (yes that's right, days). The purpose of the query was to find all "new suppliers", which was defined as any supplier whose first order was less than 90 days old. Thinking iteratively, as programmers do, the query did the following;
- Open a cursor querying the suppliers table (50,000 rows)
- For each supplier query the fact table (4 million rows) to find the min(orderdate) for that supplier
- If the min order date is less than 90 days previous to today's date, then flag the supplier as new
- Next supplier
- Close cursor
Since this was a transient data storage place that was used to clean and prep the data for final loading in to the warehouse, there was minimal indexing. Therefore, the 4 million row fact table was scanned 50,000 times which resulted in 200 billion rows being scanned. Effectively this was a poorly written nested loops join.
I just rewrote the query to the following (this is pseudo code)
update supplier s SET newflag = true from (
select supplierid from fact where min(orderdate) < [90 days old] group by supplierid) x
where x.supplierid = s.supplierid
This could also have been written in several ways, but it took the 9 day query and reduced it to 2 minutes.
I am not downing programmers. I am simply saying that they are usually not talented in database work, because the jobs are radically different. It is sort of like asking a network admin to write OO code, which is not their job so that are not optimally trained in that regard.
I thought you might enjoy the following story.
I had some colleagues that loved XML and XSLT. They had several books and magazines on XML. One of the magazines was called XML Journal. One day I told them that I was going to start a new magazine called Comma Delimited Journal and they said, "Why would you do that, it is so simple it doesn't need a magazine dedicated to it." And I looked at them and said, "EXACTLY!! You made my point for me. Thank you!"
We should NOT leave data storage standards to the whim of desktop publishers. (XML came from SGML)
I guess I'll stop ranting now. Thanks for listening to me unload.
Daren Bieniek, MCDBA, MCSE
-
XML appears to be the old EDI dressed up with a different TLA.
EDI is known for its huge overhead and unwillingness by its users to implement it the same way, so that each trading partner required special handling and testing.
-
Although I agree 100% to the article I have to face reality
I come from an egineering background an I firmly believe that there is a big difference between what should be right and what is actually happening. Take this list for example.
Cars can run on alcohol since along time - we are still using petroleum
NTSC is not the best form of TV signal trasmission - We still use it in USA
In comunications systems there are as many protocols as "standars" - There is an ISO that is supposed to ease the pain
Relational DB vendors now the lack of relational model implemetation on their products - They still concentrate their effors else where (meaning new "hypes")
XML is far from being perfect- yet is one of the very few things that even rival vendors have agreed to support
...
The list could be really long but I thought I needed to release some steam
Thank you for the thought provoking article Don. I do take may hat off like Chris said !
* Noel -
One of the best articles I have read on the evils of XML (besides my own comments to management). Now that I am boss, I have banned all XML from the shop and will not supply customers XML data. In the end, they all thanked me including the customers who no longer have to rely on programmers that are tempermental and hard to work with because they "know XML" (which seemed to be a trend for some reason). For me the bottom lines is this .... NO program can recognize any input unless it is programmed to do so. What is the difference between looking for position 12 thru 30 of a fixed record, or all of the data in record code "05" or code "Name" and having to check for <name> in XML. None .. that's what. So, what is the improvement ??? None .. that's what. It means more data to transmit, more data to store, more data to backup, longer processing times and if it is complicated data, XML can become very difficult to read beause digging thru the hierarchy of the tags looking for one particular <somedata> tag can be extreemly difficult to find and extreemly difficult to understand its relationship to the data above it (the hierarchy). If XML were really the wonder that it was touted to be, then one could extend that concept to also propose that it is possible to write only one computer program that would do everything by recognizing the data that it saw .... as my old English headmaster used to say .. "Rubbish".
Give me a flat file any day ... every computer system in the world can read it, but it still takes a programmer to make the computer process it.
-
My only question: Why did you have to spend any time researching to find your answer?
Did you think that a mass of people can't all jump on the bad idea band wagon at the same time? (i.e. "hmmm maybe there's something to it")
Or, did you know imediately what they were saying was silly and just needed to document your assertion? (so as to satisfy the people who do not think for themselves)
(wow that sounds way too full of myself... not meant to be. I really want to know if you are one of those --it seems to be-- rare people that figured it out in ten seconds of hearing what XML was.)
-
Well, it's not like I spent the entire time doing nothing but researching XML... I started out hearing about XML and its wonerous benefits. Unfortunately nothing I read dealt with just HOW XML conferred those benefits. It took several months before I got around to really asking questions because all the benefits of XML that were being talked about sounded good, but it also seemed that every one of them was already available with a well designed system anyway.
Yes, at first I thought that there must be something to it. Frankly at first I was afraid that I was just slow... If XML is so great, why didn't I get it? (I was not nearly as sceptical then as I am now!) Fortunately after I finally decided to do some real research I came across http://www.dbdebunk.com. Although I was initally put off by Pascal's ascerbic style, I couldn't find any problems with his logic, so I kept reading. Slowly, I began to educate myself on many subjects which were criminally neglected--or downright misrepresented--in my formal education. After I had begun to really grasp the fundamentals, it became self evident that XML is just plain stupid.
As I discussed the subject with many technology professionals, I was shocked and surprised at those who displayed outright hostility toward these ideas. I had expected them to "see the light." Most of my fellow DBA's were fairly quick to adopt them, but most of the programmers, specifically the Java slingers were very hostile and refused to curtail their practice of stuffing XML in the database. Their view is that a database is just a persistence mechanism anyway so why not use a data format that they were comfortable with? This quickly became a turf war between the DBA's and developers which I escallated to upper IT management with the blessing of my manager who had decided that this was a battle worth fighting. My boss asked me to take the lead since I was the most conversant with the issues. He asked me to write a document to submit to the CIO and which would hopefully force some sort of policy decision by upper management. After I wrote the paper, he suggested that I should submit it for publication somewhere. I removed references to specific systems and performance charts that I included in the origial. I chose SQL Server Central and the rest is history...
/*****************
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
*****************/
-
The poster is obviously ignorant of data management fundamentals and sound system design (and hasn't carefully read the article or the other posts). Just how is XML necessary, sufficient, or even beneficial for "universal data exchange"? What a totally nonsensical statement!
I won't waste my time responding substantively to questions (or statements) that have been responded to already!
I can't count the number of times I've been told "you just don't see the bigger picture" by someone who could provide no specific or logical arguments to support their opinions. I love discussing almost anything from technology, to politics, to religion with thoughtful and intelligent people, but discussing anything with fools is both annoying and boring.
/*****************
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
*****************/
-
I have made extensive use of XML and XSLT in an international data exchange network. All the data was and is stored in relational databases, as it should be. But the old mechanisms for exchanging that data consisted of electronic document specifications that were cumbersome to verify, exchange, extend, and alter. XML provided a means for companies around the globe to adopt a standard schema that is centrally available and verifiable against. Making the interface to their systems XML based allows for easy transformations to and from the standard schema.
I'm a little tired of hearing dcpeterson repeat the mantra that data exchanges like this could be done just as easily using other tools. How about listing some of those other tools? CSV? EDI? How do I convert from one to the other?
Stick to what you know, and don't claim to be an expert in data exchange. I agree 100% that XML is not "the answer" when it comes to storing data. And it may not be "the answer" to data exchange, but it is better than anything else I've seen in my 30 years of programming and database administration.
-
I would laugh if it weren't so tragic... A "standard (XML) schema"?? Is that a bad attempt at a joke? That's what EDI tried to be, and XML will never approach.
Your "30 years" of experience apparently hasn't exposed you to much...
I'm tired or I might attempt a longer rebuttal, and somehow don't think it would do any good--given that your arguments have already been completely refuted.
So "Have Fun" in your XML Nirvana!
/*****************
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
*****************/
-
The article is shalow. No question.
dcpetterson - I understand your views and will not try to prove anything to you. I am glad your efforts are truly appreciated in your nearrest surroundings. Good for you man.
As to XML and the relational database, well both are just stupid tools used to solve problems. Nothing more. I am equal oportunity user and choose the appropriate tool (according my vision) for the job.
I can give you real life examples where the XML messaging is the only way to resolve a problem. I can even give you examples where storing XML in a database field is appropriate solution as well. But, i wont
of course. Microsoft Decided to use XML enevelops for their biztalk platform. Well, we all know they are idiots. IBM choose to fully support biztalk platform and also choose XML as a messaging transport, but they are idiots as well. Mi3p, ebXML ... etc. are backed up by SUN and 45 other companies. But probably they dont know a shit about the truth, and probably all those mentioned above dont have one real normalized DBA to tell them what to do and why.
What a shame.
-
Wow! MS and IBM MUST know what they are doing! Thanks for opening my eyes man! I never would have thought of such a brilliant line of reasoning by myself! I must just be so shallow that I really can't see XML's rich tapestry of benefits.
Will everybody please disregard this article? I have now been lobotomized and agree completely that XML is great, XML is great, XML must be the answer.
...back to reality...
If you would bother to read the article and the associated links it should be clear that while these companies do employ brilliant people who do actually understand relational principles, they are not often LISTENED TO when it comes time to decide what features are to be included in new applications or their latest releases. Further, they are generally a very small miniority. The same situation exists everywhere, those of us who actually understand the fundamentals (or even make an honest attempt to do so) are a small minority even among the "database professional" community. The situation is far worse in the programmer community where that understanding is almost non-existent. Unfortunately, it is the programming community that is largely responsible (in combination with the marketing departments) for defining and building the applications that exist.
IBM employed both Edgar Codd and Chris Date, but both eventually quit after being completely frustrated in their efforts to move IBM toward a truly Relational Database management system.
If you could actually give even one example of how XML is the only way, or even the best way, to solve a problem--ANY PROBLEM--I'd eat my computer and retire as a Data Architect! I'm quite sure that both my computer and my career are safe. I doubt you, or anyone else will provide an example, and I'm quite confident that it would be fairly easy to debunk, so bring it on! But try not to embarrass yourself...
/*****************
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
*****************/
-
XML is good in areas that aren't really data. For instance, representing the content of web pages as distinct from their presentation. To describe such a free-format system in an RDBMS would either be inflexible and tied to a specific web design, or would probably end up as an EAV mess.
Viewing 15 posts - 46 through 60 (of 144 total)
You must be logged in to reply to this topic. Login to reply