Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-11-21 : 16:27:22
|
| Microsoft® SQL Server™ 2000 shipped more than a year ago with built-in support for storing and retrieving XML data. Knowing ongoing work would be required after the release of SQL Server 2000 in order to stay current with evolving W3C standards for XML, Microsoft began releasing fully-supported, XML feature packs to the Web in the months after the release of SQL Server 2000. Available as a free download, these XML feature packs—called SQLXML (XML for SQL Server)—extend the XML capabilities of SQL Server 2000.SQLXML 3.0 introduces Web Services to SQL Server 2000. With SQLXML 3.0, Stored Procedures and XML Templates can be exposed as a Web Service via SOAP. SQLXML 3.0 also updates SQLXML 2.0's support for Diffgrams, understanding new features added since Microsoft Visual Studio® .NET Beta 2. And supports released versions of the .NET Framework and SOAP Toolkit.Additionally, the features introduced in SQLXML 1.0 and SQLXML 2.0 are included in the download of SQLXML 3.0.SP1 includes bug fixes, security enhancements, and performance increases made since the release of SQLXML 3.0. Article Link. |
|
|
dcpeterson
Starting Member
5 Posts |
Posted - 2002-12-17 : 15:22:16
|
| Would someone please explain to me why we need XML at all? I have asked this question many times and NEVER recieved a good answer. As far as I can tell, XML is one of three things (none of them good) depending on how it is used. They are listed below starting with the least malignant.(1) XML is an overly verbose and ineficient way to transmit data. (2) XML is return to heirarchical databases that were discarded decades ago because of their complexity and inneficiency.(3) Worst of all, XML is a return to the days before databases where the application was responsible for managing data.Please enlighten me. I'd hate to think I'm missing the boat here! |
 |
|
|
Onamuji
Aged Yak Warrior
504 Posts |
Posted - 2002-12-17 : 16:00:45
|
| XML is an excellent transport mechanism for data. Since its sole purpose it to hold data, it also is somewhat standardized. So I could build an XML string from a LEGACY system and send it to a front-end application, which then does some permutations to it and stores its data in the database. I see no real reason why anyone would ever want to store XML data in a database other than the lazy developer. XML has great potential maybe, not as much for the database side of things but as far as client-server programming goes...its been very helpful...i've written many web services that have eased my application development... namely for other people that wanted to use a functionality of my application... but i didn't want to give them the code to maintain or worse that i would have to let them know that its been updated... |
|
|
|
dcpeterson
Starting Member
5 Posts |
Posted - 2002-12-17 : 16:20:44
|
| The one possible legitimate use for XML is, without question, data trasport. But to say it is an excellent method is very questionable. What makes it so excellent? Is it the fact that it is overly verbose and consumes too many system resources to parse and read? Or is it the fact that owing to it's bloated nature, it takes up too much bandwidth? (ever tried to transmit a few million records via XML?)All sarcasm aside, what does XML bring to the table for data transport? Despite the claims to the contrary, XML is not standardized. And it isn't fully "self-documenting" either. You can't just recieve an XML file and know, with certainty what each of the data elements means or how it is to be used. This can only be done if some true documentation is included. At this point, a simple text file and control file are MUCH more effecient to use. Who really cares that XML is more readable for humans? I want my systems, not people, to read data files.Another use for XML that seems pretty benign is for application configuration files. There isn't much harm in this, I suppose, except that a simple text file again is a much simpler mechanism. "Make things as simple as possible, but not simpler." -Albert Einstein |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-12-17 : 16:47:46
|
I agree about the bloat, and the fact that it's not perfect, but it is much better than having to go through 4 different data formats between 2 sources...I've done that far more times than I care to remember. CSV and tab-delimited are great, but they have NO descriptive info or metadata at all, nor can add any kind of constraints or validation to it. And you'd be surprised how many older systems won't directly support even CSV or tab files!quote:
You can't just recieve an XML file and know, with certainty what each of the data elements means or how it is to be used. This can only be done if some true documentation is included.
When done properly and fully, XML and XML Schema WILL allow this, but you're right, it depends on the source you get it from. It IS a standard BTW, meaning there is a committee working on it, and that is has openly published specifications, and all recommendations have to be reviewed and approved. Most software developers are going to use it at some point, like it or not. If you don't want to use it, don't; I don't either. But sooner or later it will become utterly prevalent. |
|
|
|
dcpeterson
Starting Member
5 Posts |
Posted - 2002-12-17 : 17:26:26
|
quote:
I agree about the bloat, and the fact that it's not perfect, but it is much better than having to go through 4 different data formats between 2 sources...I've done that far more times than I care to remember. CSV and tab-delimited are great, but they have NO descriptive info or metadata at all, nor can add any kind of constraints or validation to it. And you'd be surprised how many older systems won't directly support even CSV or tab files!quote:
You can't just recieve an XML file and know, with certainty what each of the data elements means or how it is to be used. This can only be done if some true documentation is included.
When done properly and fully, XML and XML Schema WILL allow this, but you're right, it depends on the source you get it from. It IS a standard BTW, meaning there is a committee working on it, and that is has openly published specifications, and all recommendations have to be reviewed and approved. Most software developers are going to use it at some point, like it or not. If you don't want to use it, don't; I don't either. But sooner or later it will become utterly prevalent.
|
|
|
|
dcpeterson
Starting Member
5 Posts |
Posted - 2002-12-17 : 17:42:11
|
Boy did I ever screw that one up! Let me try again...quote:
CSV and tab-delimited are great, but they have NO descriptive info or metadata at all, nor can add any kind of constraints or validation to it.
If it is used strictly as data transport, then the issue of constraints and validation is moot. The source system should enforce those and the destination system should as well. In order to move data, both the sender and reciever must agree on what the data means and on the rules that govern its creation and use. Besides the integrity checking in XML is weak at best. quote:
It IS a standard BTW, meaning there is a committee working on it, and that is has openly published specifications, and all recommendations have to be reviewed and approved.
Yes, there is a committee, but there is no defacto standard that everyone uses. There are many parsers out there and many of them do not conform to the "standard." Many programmers are taking shortcuts in creating their XML docs etc... It seems to me that the committee is largely whistling in the wind.There was another post that indicated that XML wasn't intended as a data management platform. I agree, but the fact is that it is being used that way in all too many cases. This is where I really have problems with XML, the data transmition function is a MUCH less problematic issue. The problem is that there seems to be so many "IT professionals" including those who claim to be database experts who think that this is good practice. They often say that XML is better for storing "unstructured data" (whatever that means) than a database. These same people don't realize that unstructured data is garbage, data is only turned into information within a context (structure) and that their lack of effort to properly model their data will cost them dearly in the long run. |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2002-12-17 : 18:04:08
|
quote:
The problem is that there seems to be so many "IT professionals" including those who claim to be database experts who think that this is good practice.
Absolutely!When you are involved in conversations like this :Person A : "What do you use for data storage ?"Person B : "We are using SQL Server"Person A : "We are building this system with an XML database. Have you considered re-writing your system with an XML database ? I think you should."* names changed to protect the stupidIt just makes you want to cry.Too may "IT professionals" throw away years of "best practice" and embark on totally useless projects just for the sake of buzzword compliance.That said, XML is really good at storing small amounts of text data, particularly configuration data. It is human readable, and easily editable with a text editor. Once it gets big of course, it becomes useless due to the time taken to parse and retrive.It is also great as a publishing format for text based content that needs to be read in different formats. XSL is a nice way of making that happen.As mentioned, data transport is another good use. Yes, you still need to negotiate schemas on each end, but it is easy to transport over HTTP and the abundance of XML tools on pretty much every platform make it a good choice.So, I use XML, I like using XML, but like any technology you need to assess the best tool for the job. Too many people don't do this.Damian |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-12-17 : 18:07:23
|
quote:
In order to move data, both the sender and reciever must agree on what the data means and on the rules that govern its creation and use.
 Heresy! What would all of those data transfer consultation companies do if people could AGREE on a universal data format?  They'd go out of business, that's what!You're absolutely right of course, and you are living a very charmed life if indeed you're able to do that even 10% of the time. Realistically speaking, that never happens, and the best way to have someone actually review the structures, data types, constraints and so on is when...they're creating an XML file for data transport. |
|
|
|
|
|
|
|
|
Article: SQLXML 3.0 SP1