Is XML the Answer?
-
How to kill a SQL Server.
Allow developers to use sp_xml_preparedocument in their stored procedures. It gives the enterprise edition of SQL2000 the concurrency of MSDE.
-
Great article Don
I never had any issues parsing text files using awk , usable both on unix or windows. But I know this kind of tool, perl included, is not considered by many IT managers as *professional*. Some prefer to spend dozens of man/days to compile their own parsers - xml compliant of course - and put in the garbage a 10 lines awk or perl script which does the same thing. Why not.
But this is not the purpose of this post. Just to let you know of the kind of product my company had to test.
On a NT box, an application, using mssql server. Central table contains 252 columns, 77 indexes on it, and text columns of course, containing... xml. But this is not the worst. Persons who developped this software considered this sgbd could not guarantee transactions. Then, every single operation within the program, writes it into a flat file and then applies transaction into the database. You already guessed how this file is formatted...
xml to mirror transaction log. We are far, far, far away from data transport or webservices.
Fred
Sybase/Oracle/SQLServer/... and XML administrator.
-
Great article Don.
As the insufficiencies of XML became known, another solution has come forward.
"The Resource Description Framework (RDF), which integrates a variety of applications using XML for syntax and Universal Resource Identifiers for naming the sources."
Web Ontology Language is also part of the standard.
See http://www.w3.org/2001/sw/ for the latest standards and news.
SQL = Scarcely Qualifies as a Language
-
I hadn't heard of RDF before, but after a quick scan through a couple of documents it looks like it's nothing more than XML shorthand. I does seem to address the problems associated with bloat, but it of course does nothing to address the problems associated with hierarchical data management.
So RDF could be the solution to the most obvious (but also the most minor) of XML's problems, and frankly if it were limited to the realm of data exchange you'd get no argument from me. But experience has shown that the next industry buzzword just might be "RDF Database Management Systems." Maybe some genius at MS will come up with the idea of creating an RDF data type in SQL Server 2008 when they could be wasting their time delivering truly useless features like distributed keys, complex declarative constraints, updateable views, and better physical/logical separation etc...
/*****************
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
*****************/
-
Just noticed the post...
I'm familiar with Cache. Sure hierarchical dbms'es are fast at storing/retrieving hierarchical data, as long as the structure doesn't ever change. For data that isn't inherently hierarchical (most of it isnt') and for which there may be a need to preserve many different hierarchical representations that might change, hierarchical data management falls flat on its face.
Reading the Cache Systems press releases you would think that anyone would be crazy not to use it. But then how do you explain that despite years on the market and a healthy marketing budget, the actual market penetration of this--and other hierarchical/OODBMS's--is miniscule? The answer is simple, they utterly fail to live up to their hype.
/*****************
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
*****************/
-
Nice article (even if I am a bit slow
). I have found one use that I like for storing xml in a database. Persisting record state. With a single table and a few fields I can easily accommodate any record(s) that need to be stored including calling trees for lookups. I store both the original record and the current (edited) state of the record. When it's time to save I can do a three way merge and actually tell if there's an update conflict that should be resolved or if the updates are non-overlapping, even if the update occurred a week after the record was grabbed. The best part is I don't have to model every table in the database or maintain hashes or version id's to tell if there's been a change and I can display exactly what happened to help resolve any conflicts. There is one constraint I do place on the use though. I read and write only via a session key and all inspecting of the data is done in the app in an XML document, not on SQL server. -
Don, nice first article, risky to say the least, I cant wait for your second!!
What are you going to tackle next, "does god exist"..haha
I must say XML data types scared me a bit to, but always remember this saying..."Horses for coarses". It means this, you dont "have" to store your data as XML any where, its now just an option, use it if it suites. Remember the main reason XML was invented.."Standardisation" for communication. Is XML the best for this, I have no idea, but I dont see alot of other technologies putting there hands up for the job. If XML makes communication easier between everyone, then for christs sake, dont stand in its way, its something that has been sadly lacking from all sides of the computer industry, and now that some of us are finally "talking" to each other, I dont wanna go back!
Brett Anthony
C++/C# Dev.
-
Great Article! I've been saying this for years.
No one seems to realize that XML is nothing in and of itself. It's a metalanguage. All the books/articles/whatevers always seem to say "now, you have a schema, then..." Creating the schema/DTD/data model is the hard part, the rest is just coding.
Agreeing on a data model is hard, but really doesn't require an XML language to do it in.
That said, I have found just one example of where XML is actually useful: marking up text. Imagine that!
XML is the technology of the future, and always will be.
-
Thanks Don, there was I thinking "I don't get why XML is useful to me" and I was being a bit of a thicky, when really it just isn't any use to me.
I can see an advantage where you're advertising a data request and you don't necessarily know who is going to be responding (for example EDI between many suppliers/customers or a site accepting data from many different sources (eg fish4)).
However, where your data definitions are well understood and you control both ends of process (I'm punting data between different sites around the world) it serves no useful purpose whatsoever, in fact it just adds an encode/decode layer you don't need.
Oh well, I guess I'll have to wait a bit longer for that six figure salary.....
-
DC... thanks for the great article. Like many have said, it has sparked a bit of a controversy both pro and con. It's articles (and the related responses, inflamatory or not) like this that make everyone step back and think.
Additionally, to support a pig by saying that feed is getting cheaper is ridiculous ("Bandwidth will get cheaper as will storage space").
Well said, Daren. I also agree about the RBAR (Row By Agonizing Row) methods of data processing that many undertake. Those folks have no clue what a database is supposed to do be it relational or hierarchical in nature.
For those that say performance isn't important, then stop using a telephone, email, and instant messaging and do everything by snail-mail. Yes, yes... data integrity is absolutely the most important factor but accomplishing any given task in a couple of minutes instead of 12 hours with the same amount of data integrity does have some value (as my Boss says "That's friggin' huge!"). Performance is the second goal of computer usage and it cannot be ignored.
I agree that XML allows for the easy transmission of hierarchical data but at the cost of bloated files. Having the equivelent of two column headings for each piece of data seems terribly ineffecient especially when the nature of the data dictates that each column of data must be present. XML is RBAR on steroids. Since I deal with mega-row data transmissions of call detail records from telephone companies, I'm very happy to not have to wait for the extra overhead of two tags per element to transmit. The single row of delimited column headers at the top of a 30 million row transmission suits me just fine and is a heck of a lot more efficient even on zipped files.
Yes, I agree that XML files support unagreed upon data structures. If it's your nature not to come to some agreement with your prime data providers, then I'd say you have bigger problems (not to mention bloated file sizes and extended transmission times).
And I would not be any more likely to store a transmission format like XML in my database than I would be to store the raw CSV or fixed field rows in my database. That's not what the database is for. With all the tools to parse XML or create it, there is no reason to bloat a database with XML data.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Thanks Don. Even in the non-DB area like UI programming, XML seems to be creating more problems than it solves.
I'm neither a DBA nor a data integrator, so my views are not biased. I get frustrated to see so many developers wasting their time in "programming" for XML in the middle tier layer. Bizzare ideas like DB -> XML -> data processing in middle tier happen.
XML is definitely the most hyped technology in the recent past.
-
"..'Standardisation' for communication. Is XML the best for this, I have no idea, but I dont see alot of other technologies putting there hands up for the job."
Actually, for data transmission purposes, if you'd like some metadata to go along with your data, but don't want the wretched excess that XML languages create, YAML seems like a very nice alternative.
Caveat: haven't used it myself. Also, at first glance, it seems like COBOL records 3.0, tho' again, caveat, haven't studied it extensively (yet).
-
Absolutely. I have now been on two different projects in which the developer teams both independently (I.e. without me beating them over the head) concluded that XML was poison when it came to performance and completely scrapped their plans to use it anywhere.
Now if I could only get them to snap out of their OO trance...
/*****************
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
*****************/
-
Dan,
I think that your article is accurate and fair. I enjoyed reading it and actually laughed out loud at some the stuff I read by following the links. I have long thought that XML is just another cover-up by technologists for their failure to understand :
1. How their company makes money.
2. The real heart of the business problem.
3. Poorly (I mean really really bad) designed databases.
4. Rotten (I mean some of the worse) programming that allows incorrect data to infiltrate the database and the organization.
Rather that fix the basic human skills required to build a really good Data Processing Department, we have invented instead the Information Technology department. One tried to process data to the best of its ability, the other tries to implement technology to the best of its ability .. the results are entirely different as are the goals.
I would not think that any proponents of XML, XSLT, or any other "buzz word technology" could implement a good data processing solution any better or any faster than a couple of good old boy programmers who know what they are doing, understand the businsess problem and *care* about the business, and have more than corn meal mush between their ears. The biggest problem with XML is that like all other technology advances, put in the wrong hands, things get worse, not better and the degredation is not just isolated to a few companies but becomes wide spread very quickly.
As to interchangeablity of files across platforms .. what the heck is ANSI and ASCII about if not that ? I never saw a computer that couldn't read a text file.
Del
PS .. Let the flaming begin
-
It's generally not a good idea to use turnips to create pizza dough; a mustache on a halibut just looks silly. Similarly, using an XML language as a database, or a data transfer medium isn't really a good idea. Just look at the language: XML languages are used to markup a document. There are several very good DTDs out there specifying how to markup particular types of documents. SGML languages (of which XML languages are a subset of) have been used for years to markup documents.
It's funny how IT people sometimes need to learn to just give up. For example, the waterfall project management methodology has been around forever, doesn't work, has never worked, and never will work. Lots and lots of smart people have worked very hard at making it work, but after 20, 30 years or so, maybe it's time to stop banging your head against the wall. Similarly, XML has been around since 1997 or so, and (with the above exception noted), only works in trivial applications. When are people just going to give up?
Viewing 15 posts - 76 through 90 (of 144 total)
You must be logged in to reply to this topic. Login to reply