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 ««123»»

For SQL Server, XML Is One Answer Expand / Collapse
Author
Message
Posted Thursday, October 23, 2003 6:09 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 12:01 AM
Points: 2,711, Visits: 33
And now to the topic again...
I do believe adding XML support to SQL Server is good. It gives you an additional interface to the system.



Post #83810
Posted Thursday, October 23, 2003 9:37 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 21, 2004 10:57 AM
Points: 42, Visits: 1
Someone asked about the theory behind XML. I'm not aware of any formal/mathematical theory, but I guess there is one related to the hierarchical, tree-structure of the way the data is stored.

Here's a few links that may be helpful. XML is a standard developed and maintained by the w3c organization at
http://www.w3.org/XML/

According the orginal working document on XML,
"The design goals for XML are:

XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness is of minimal importance. "

To understand where XML has come from, you have to look at SGML. Here's a history:
http://xml.coverpages.org/general.html#hist

hope that helps

dave





Post #83811
Posted Thursday, October 23, 2003 9:50 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, November 17, 2014 2:18 PM
Points: 1,035, Visits: 411
quote:

I must admit to being confused by your anger. Your criticisms do not appear directed at the position that I took.




There is no anger on my part; frustration at the total lack of understanding? YES, but not anger.

quote:

There are simple, common sense rules built in to XML that do not come with CSV.

--The ability to nest records in a readable manner.
--The ability to specify and validate data format and types outside of the application code. (XML Schemas)
--The ability to specify that additional data or data fields can be transmitted, at any level, without affecting the receiving application. (Open specifications)
--The ability to specify character encoding (useful for languages that are not based on the Latin-1 character set).

Even X12 EDI doesn't do all of these things.



X12 EDI does not do these things because these are NOT functions of a transport mechanism. I don't need the transport mechanism to enforce any kind of integrity because it is enforced at the sender and at the reciever and the data is not modified en route.

You seem to not understand that as soon as you start to take on these functions you have a data model (good or otherwise) and you are performing data management. XQUERY, XML Schemas and all these other wonderous capabilities of XML that you seem so excited about ARE DATA MANAGEMENT functions!!! Now, if you are managing data with XML, once again, what is the sound logical foundation you are using?

I'll not argue the endless virtues of CSV files. It was just the most familiar example to give for demonstration purposes. But of course, any file used for data transmission MUST be accompanied by COMPLTETE and PRECISE documentation. In my article I argue, and common sense will show, that XML tags are not sufficient documentation in an of themselves. So, if your "self describing" format can't describe itself FULLY, why bother? In this context the tags become superfluous.

As for your example of the Dolphin. Cute, but totally inappropriate. You and others are constantly saying "XML is just for sharing data" and then turning around without even knowing touting its benefits as a data model.

I am trying to help people see:
1. The relational model is the only viable choice available today for data management.

2. XML is a bad choice for data management. And that many of the "most exciting" things being done with XML ARE data management functions.

3. XML isn't even a very good choice for data transmission. XML's self documenting features are wishful thinking at best and it's bloated.

As mdburr stated, all the benefits of XML are not due to XML itself, they are due to the bandwagon effect. And while there is something to be said for standards, XML is a bad one all the way around, so why support it?



Edited by - dcpeterson on 10/24/2003 10:31:51 AM



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

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 #83812
Posted Friday, October 24, 2003 9:28 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, January 10, 2004 9:34 AM
Points: 3, Visits: 1

Is there any reason to compare XML to CSV?

Write

<root><![CDATA[
..contents of your CSV file..
]]></root>

and you have XML file.
Yes, need to escape "]]>".
Yes, need to add some funcionality to your CSV parser to skip first and last rows.
But yes, you can include all the family of CSV files, etc. This will need a little more logic from your parser.
But someone wrote and test this, and name it XML.




Post #83813
Posted Friday, October 24, 2003 10:20 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 7:59 AM
Points: 354, Visits: 67
Bottom line...XML support provided by SQL DBMS's, I could care less. If developers want to struggle with the syntax of some FOR XML clause, who care's? If that SQL statement, like any other, consumes too many resources, it will be throttled.

Now, one argument or beef with the vendors is, developers want to store the XML within the DBMS. Why would ANYONE want to do this? Because it is not currently provided, they store it in a VARCHAR, create an ID attribute, and call it a database. What a lousy way to manage data. And why would anyone want to go to the expense of purchasing an SQL DBMS to only have it tag and stuff a text bucket? And now, the vendors, Microsoft included, want to include a native XML data type to make this stuffing...what? more functional?

That is what the relational model is all about: identifying and constraining the elements and relations of the sets of data. XML can not even begin to come close to addressing these storage, constraint, quality, and retrieval requirements.

Make no mistake about it: many would be developers without any formal training, and many who do, want to transport these XML documents directly into the DBMS. Once this happens, not only will the XML not be able to fulfill the requirements of a flexible, reusable, data model, the DBMS will be rendered useless to this task as well. All knowledge of the set elements of the data will have been consumed and badly digested into the XML stream stored either as a text BLOB/CLOB or some idiotic XML data type.

The very idea of an XML data type is an oxymoron. Data types are one piece of the DOMAIN construct who's sole purpose is to constrain and add quality to the data storage/management. How is XML constrained? A schema? But that's a DBMS. How thick can some of you people be?

Time to go to class, grow up, and get a real education. These do-it-yourself in 21-day books you've bought are doing us all a disservice.


Edited by - iapetus on 10/24/2003 10:27:39 AM



Post #83814
Posted Saturday, October 25, 2003 2:52 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, August 29, 2004 3:57 PM
Points: 50, Visits: 1
quote:

Now, one argument or beef with the vendors is, developers want to store the XML within the DBMS. Why would ANYONE want to do this?


Seems wrong headed, doesn't it?

I think I can guess the reason that storing XML inside SQL tables is distasteful to many database designers: XML clearly contains data fields, and the developer who stores data as XML is not allowing SQL Server to manage that data.

So, think about it... what other times do you store data in the database where the data has valuable content, but the database does not manage it? How about scanned images of documents... or any other image where the image contains content that the database cannot "see" (signatures, pictures of catalog items, encrypted password hashes, PKI certificates, you get the drift).

The fact that SQL cannot manage this data, we become resigned to the idea of storing it in SQL as a BLOB.

But XML is readable, and that makes it abhorrent to store it in the DB as a BLOB. In other words, if XML wasn't so readable, most folks wouldn't be so miffed about storing it in a database!

But there's two advantages of SQL Server that act as a disadvantage in some specific situations:

1) SQL has a fixed set of heirarchical levels. If your data does not, and you only need to store it (and not manipulate it), then SQL Server is overkill.

In the past, we'd put the data in some alien format, store it in a file, and put the file name in SQL. Now, we store the content in SQL Server as well. Same difference.

2) SQL makes it easy not only to find a field, but to change it. What if we don't want that? What if a set of records that represents a single very complicated document is only valid if it never changes?

Storing it in a tool where the tool provides easy access to each field adds the burden of proving that the fields haven't changed. This is ESPECIALLY true if the data is normalized, since a change in an independent table will be reflected in all referring transactions.

In this case, it is sometimes helpful to put the XML document in a field as an audit item.

quote:

That is what the relational model is all about: identifying and constraining the elements and relations of the sets of data. XML can not even begin to come close to addressing these storage, constraint, quality, and retrieval requirements.


If you accept the constraints of relational models, that being a predetermined and static set of relationships, RDBMS is appropriate. However, over 90% of all business information is not stored in relational database systems. While much of this could be managed relationally, some if it cannot. For these folks, a pure RDBMS implementation is either insufficient or inefficient.

One exciting development: Using Microsoft SQLXML, you can load an XML document into SQL, and it will break out the data from the XML structure and store it in relational tables and fields... No more excuses for those people who intend to use the data in a relational manner.
quote:

The very idea of an XML data type is an oxymoron. Data types are one piece of the DOMAIN construct who's sole purpose is to constrain and add quality to the data storage/management. How is XML constrained? A schema? But that's a DBMS.


Sometimes the developer wants no constraints on this data item. Sometimes, he or she wants to mix Relational data with structured heirarchical data. There is a place for this data type.
quote:

How thick can some of you people be?
Time to go to class, grow up, and get a real education. These do-it-yourself in 21-day books you've bought are doing us all a disservice.


Not directed only at you, but... I'm dismayed by how freely fellow developers are attacking each other in these forums.

Can we keep the conversation civil? Neither of us have any idea how qualified, or unqualified, the other members of this board may be.

Ideas are open for criticism, and rightfully so. However, we will all learn much more from each other if we refrain from attacking the people who post them.




Post #83815
Posted Monday, October 27, 2003 4:11 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Monday, November 17, 2014 2:20 PM
Points: 6,800, Visits: 1,914
I concur that we need to remain civil. Overall both this article and the original have evoked a good deal of discussion - good discussion! I'd hope that each might learn something from the opposing view.

Maybe Im old, or not old enough, but I rarely see black and white anymore, lots of gray in the world. Very few things are absolute.

Andy
http://www.sqlservercentral.com/columnists/awarren/




Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #83816
Posted Monday, October 27, 2003 9:09 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 7:59 AM
Points: 354, Visits: 67
Oh...the confounding of the masses!

I believe most of the replies given to my criticisms were in agreement, mostly, with the notion of NOT storing multi-valued attributes within a single field specification when that tool will only support single-valued elements.

I agree that if you stored the XML content with the expectation that it was static, for instance the XML schema definition itself as opposed to the XML content, and were prepared to treat it as such, then, a BLOB/CLOB data type would seem appropriate.

The beef I have, however, is manifold. History has shown us that hierarchical structures, although present, are rigid, inflexible, and administratively burdensome. The relational model is much more highly flexible, even to the point of creating models of data models not just the content itself, thus, producing the dynamical flexibility that many developers tout as one of the strengths of XML.

The point is that MS SQL Server, Oracle, DB2, Sybase, et. al. are SQL and attempt to be Relational DBMS’s. To subvert the relational model by providing for multi-valued content without the proper database management functions to constrain, quantify, and validate that information breaks the sole purpose for providing the DBMS to begin with.

Let us not forget; there are hierarchical and multi-valued DBMS platforms available out there. Does anybody remember dBASE, FoxPro, Paradox, Progress, Informix, et. al.? Those are antiquated technologies. Although many data administrators and developers may still support such monstrosities, can anyone argue the superior benefits of these systems over the relational systems?

Predicate Logic and Set Theory, the foundation for Relational Systems, says little to the elements of the sets other than the constraining factors of their respective domains, but merely the constructs for the relations between sets and the operations that may be performed on them. The model can be extended far beyond the content of data in raw form to include data structure as content and higher abstract models as data content too. This is much more highly flexible than the rigid structure that XML imposes upon us.

As to my incivility, with regard to peers, my apologies, however, I am inundated with so-called data and database "developers" who do not have the first clue as to what data management is or how to employ the tools available to optimize such management. Moreover, it is these "nitwits" that are usually the first to jump in line with the other lemmings following the piper vendors on every new fad purposed without thoughtful examination. Moreover, these are the ones who misuse the tools most often because they have no basis to evaluate the correctness of their solutions, no historical knowledge or experience with the antiquated concepts in order to defend their creations.

As you yourself expounded, the developer needs this, the developer requires that. True, the database developer may or may not need such solutions. However, how truely qualified are many of the application developers who also see themselves as database development "experts"?

In my opinion, an application developer and database developer for over two decades, one who remembers the days of ISAM, VSAM, dBASE, Foxpro, etc., and now, a fully qualified database administrator as well, the evidence of the use and misuse of such technologies as XML, I stand by my comments: put down the "Teach Yourself in 21 Days" books and do a little "REAL" research as to the design and purpose of database systems.

If you want hierarchical storage, bleed at your own risk, but keep that garbage out of the Enterprise's Relational system. As database system administrators and developers, it is your responsibility to fight against such insanity and to educate the lower beings on the proper usage of such tools. A wise person would recognize their inadequacies and defer to the wisdom of the more-learned colleagues. Quit following the market-speak, listen to your elders, question the wisdom of your actions, you arrogant pups. Some of us have been around the block a few more times than you. You could learn a thing or two that might really do someone, in addition to yourself, some real good.



Post #83817
Posted Monday, October 27, 2003 9:47 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
>>Quit following the market-speak, listen to your elders,
>>question the wisdom of your actions, you arrogant pups.

Who are you talking to here?

How about addressing some of the points made in Nick's article, for or against?

In my opinion, Nick has made some excellent points and made them well. He's even taken the time to write an article which attempts to put the discussion on a more constructive footing, and then gone on to respond to comments constructively -- even when these comments appear to have been written without any reference to what has actually been said. To me that's a reason to listen to and respect someone, whether you agree or not. The fact that you are a "qualified database administrator" amounts to little -- I'm sure the people who signed off Enron's books were qualified accountants.

Trolling in these forums is something I've never seen, but in this case I'm reserving judgment :)




Post #83818
Posted Monday, October 27, 2003 10:21 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, November 17, 2014 2:18 PM
Points: 1,035, Visits: 411
quote:

I concur that we need to remain civil. Overall both this article and the original have evoked a good deal of discussion - good discussion! I'd hope that each might learn something from the opposing view.

Maybe Im old, or not old enough, but I rarely see black and white anymore, lots of gray in the world. Very few things are absolute.



Andy and others...

I agree that the discussion has been desperately needed (hence my original article.) I have also been tremendously gratified by the response. I frankly didn't expect the article to get published at all. That it was is a testament to the editorial teams' fairness and open-mindedness. When it was published I expected a largely negative reaction given that I as "attacking" one of the hottest trends in the business. That the responses were, for the most part, fairly well reasoned is a testament to the quality of the SQL Server Central audience. Many thanks to the SQL Server Central team and to the community in general.

That being said, Chris Date introduced the concept of what he called the "incoherence principle" which states "That which is incoherent is difficult to treat coherently." Some replies could be poster children for the incoherence principle, and in my replies the diffuculty of dealing with them in a rational manner may have shown through in the form of frustration. For this I appologize, especially since I know that the worst way to convince people is to insult them.

However, as a DBA I can't afford to allow poor practices to jepordize my data for the sake of getting along. In fact you could say that many of us DBAs have made careers out of frustrating developers For as long as I have been in the business I have had to tell developers "NO." XML is just another iteration of that cycle.

If the developers could have their way, we would have no constraints on our data at all! I wish I had a dollar for every time I've heard one complain that I am making their job difficult because I won't (more properly the database won't) let them do something. In almost every case, they are absolutely correct and the thing they are wanting to do SHOULDN"T BE DONE!

Now, don't take this as a slap at developers in general. "Some of my best friends are develpers!" To be certain, there are many who understand the importance of data management, but in general their focus is much different so it becomes my job to force the issue.

Many of the arguments for XML are essentially: "But XML makes using these poor practices soooo easy, and the vendors all say it's O.K..." But the real problem is that many are so ignorant (not stupid) that they don't even realize that what they are wanting IS a "worst practice." And since it is somewhat disguised by industry hype, many who should know better are fooled too.

Andy, you can't be as old as you intimate if you don't recognize the pitfalls of hierarchical 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



*****************/
Post #83819
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse