May 2, 2008 at 7:59 am
First, Great article...fairly objective (more neg than positive but realistic).
Just chiming in on my experiences dealing with XML in a DB aspect.
- MS has gone so far as to create a datatype around XML (XML datatype in SQL Server 2005 -> 2008) so it's here to stay from an MS aspect (at least for these versions of SQL Server). This could have been just a response to "industry" but enough people must have said "we want it"
- Advantage of XML datatype that I've found? The jury is still out. The experiments I've done so far are based on search requirements. Instead of building "dynamic" sql for search needs, thought I could use XML representation of data to search on and ,literally, have my egss in all on basket but a) XML is case sensitive...searching on is not a big deal but try displaying data all in lower case :oP, b) Full Text Search ignores tags so you just might as well search a text file, c) (Newbie) on same vein as a), trying to use xquery to search on the data caused me more headaches than solutions and performance was dismal and d) storage requirements, at least so far I've noticed, have reduced with the use of xml datatype for the set of data.
- With todays user requirements of "customization" needs, xml in an RDBMS model, I beleive, is a possible answer to how to manage/store user specific configurations/customizations that a "fixed" data model may have trouble managing. Again, I'm still in experimental mode but instead of having fixed models (restricts user to number of items if stored in single table (1024/8KB for us MS guys) / dynamic creation of tables (Oh my, how many tables :oP)), I'm leaning towards having the xml store the custom fields but also requires me to store the resulting data collected from these fields in a related XML format...I could be shooting my self in the foot but again...experimenting
With all that said, I've always toted xml as a data transfer tool, it may be bloated but it's cross-platform and if done right, opens more communications doors than closes but with all my other experiences, be very wary and experiment. A couple of weeks worth of hard core run throughs with real world data can save you years of hacks and torment.
Dave
May 2, 2008 at 8:51 am
Someguy (5/2/2008)
Wrong: The things for which XML is useful are make it VERY useful. It provides a standard for inter-system communication that allows developers to avoid re-inventing the wheel for every new customer. The failure of people like the author to miss this point amounts to nothing more than just plain laziness and pig-headedness.
Hmnn indeed. I don't know whether you've had a chance to read through those 12 pages (which I'm glad were included at the re-publication otherwise we'd need all those comments to be made a second time), but Don does cover this point off several times. Even if he did miss the point, I wouldn't call that lazy or pig-headed - I'd call it a mistake on his part or a disagreement on yours. Either way, not sufficient grounds for hurling insults. This shows why it is important not just to read an article, but to read the feedback as well.
John
May 2, 2008 at 9:06 am
Someguy (5/2/2008)
Hmnn...By the time I'm getting here, we're on 12 pages of replies. Admitting that only a handful of people will read this far, I might as well throw in my 2 cents.
(As a note to the publishers, when you re-print an article, don't mindlessly include all of the original comments - you make new comments almost worthless)
This article is everything that is wrong about the computer field and a few things that are right.
Right: XML is not the answer to everything. Nothing is. It is a tool to be used when it's useful. Yes, it's a shame that simple tools get raised to the level of messianic proportion by novices and greedy vendors. And storing XML in a relational database just makes the business of managing the database more complex while adding dubious value.
Wrong: The things for which XML is useful are make it VERY useful. It provides a standard for inter-system communication that allows developers to avoid re-inventing the wheel for every new customer. The failure of people like the author to miss this point amounts to nothing more than just plain laziness and pig-headedness.
Nuff said...
Mindlessness...Laziness...Pig headedness... traits all very evident in your post. On the positive side, I did get a good chuckle out of it though...
Yes, XML has become a defacto standard, and enjoys many of the benefits that any standard does, but objectively, it is a stupid standard as standards go.
The failure of readers like you to grasp points that are made in the article and that have been amplified, clarified, and reiterated in the subsequent discussion "amounts to nothing more than just plain laziness and pig-headedness" and I might add it's tiresome 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
*****************/
May 2, 2008 at 9:53 am
Mr. Peterson,
thank you for putting a smile on my face this morning. (why, oh whydid I flag this thread). You, curmudgeon you.
This current rebirth is classic 5 blind men and an elephant.
Dynamic data? Business needs vs. IT engineering? intersystems communication?
I get the feeling that this thread is off the rails a bit.
But I want to thank all for the good laugh this morning. It was sorely needed.
Here's something new for those have obviosuly have time. Is there an Object-oriented database that persists methods within each object? (loaded question)
The XML debate is rather moot as it has been pointed out earlier. We'll go along like good little sheep as we did when 3GL languages became the rage and relational db's forced old COBOL programmers to retirement, and so on and so on.
Meanwhile newbies can sit and pine for the next new messiah-like technology to eliminate the need to think and understand.
Hey, I know, Let's go back to the Software engineering wars. Oh, sorry, all that required was listening to you customers and responding to their needs. what tool the engineer uses is of no concern to anyone.
:hehe:
Frederick Goodrum
May 2, 2008 at 10:08 am
I just want to thank the author. I have limited exposure to XML, and as a result have never really thought about it.
I think in the future I will make the distinction between interfacing and storage. XML for transportation and interfacing, definately not for storing.
Thanks for getting me thinking about XML!
May 2, 2008 at 10:31 am
Well, yes I did read the 12 pages and my comments still stand.
Of course, it may be that I'm a little lazy, too. Just this morning I had to open a configuration file for an errant program that I wanted to learn more about. I was happy to see that it was written in XML. So, I could understand it. Without XML, it would have been written in someone's proprietary format which would have made perfect sense to them, but little sense to anyone else. I'm happy that whoever wrote that file took the time to be familiar with XML. It saved me the hard work of spending all morning jumping around the internet trying to find some hint of what a mysterious file format might contain. I'm happy that the writer didn't say "Oh, XML is just a gimmick. I'm so smart that I'll write something that's much more efficient". I consider such a person to be pig-headed and lazy. They only want to do what's comfortable for themselves with the rationalization that they're smarter than the rest of us. Because I'm a little lazy myself, I prefer to work with developers who keep up with modern standards.
Consider the VISA commercials where everyone runs through a store and swipes their credit card through a reader. They're happy because they get out fast. The vendor is happy because he gets his money faster. Then someone whips out a checkbook and throws the whole line out of whack. Are checkbooks evil or wrong? No, they're just inefficient compared to other ways of payment. Is VISA the answer to everything? No, but if everyone used one when appropriate, things would go a lot faster. XML is like that - if people would use it (when appropriate) life could be a lot easier for all of us. Flat files are like the checkbook. They made sense 20 years ago and maybe today in some specialized situations, but little sense today.
Hey, if you want to create job security for yourself by re-negotiating standards for every new application, and your managers are stupid enough to put up with it, create all the flat files you want!
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
May 2, 2008 at 10:34 am
Thanks for thinking! That was my main goal, to get people to THINK instead of just accepting what vendors were feeding us.
One quick correction if I may: Yes, there is a differnece between interfacing and storage, but a datbase is NOT for data storage, it's all about data MANAGEMENT, or at least should be...
/*****************
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
*****************/
May 2, 2008 at 10:45 am
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.)
May 2, 2008 at 10:57 am
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
May 2, 2008 at 11:31 am
Have read this article a few times now since it was originally published. Still as relevant today as 5 years ago. I hope Steve will continue to bump this one at least once a year!
Good job, Don.
TroyK
May 2, 2008 at 11:44 am
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
*****************/
May 2, 2008 at 11:50 am
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/
May 2, 2008 at 12:14 pm
"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! 😛
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.
May 2, 2008 at 12:16 pm
"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.
May 2, 2008 at 12:21 pm
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
Viewing 15 posts - 121 through 135 (of 144 total)
You must be logged in to reply to this topic. Login to reply