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

Is XML the Answer? Expand / Collapse
Author
Message
Posted Tuesday, October 7, 2003 8:11 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, October 26, 2005 3:09 PM
Points: 3, Visits: 1
First, many putting down XML have apparently never dealt with ANSI interface standards. If you think ANSI record layouts can not be helped by XML organizing the data then you are sadly mistaken. But again, this is a cross platform transportation model.

I also find it somewhat amusing that people still believe relational databases are inheriently better than hierarchal. There's no one solution fits all. Have the OO arguements taught these people nothing?

Self describing data is a joke. Even in relational database (column name) it's a joke. The end result is whoever is using the data needs to understand the data. Let's not make this more complex than it needs to be.

XML does offer a "universal" way to pass (complex) related data. Delimited files do not offer this.

This article begs of typical bad research. He took a point of view, then found examples to support that point of view.

Lastly, the idea of a record being 4 times bigger, well it's all relative. If a record is 4 times bigger, but the small record is only 100 characters and the big record would then be 400 characters it doesn't matter on networks. They will both fit in a single ethernet packet and no additional network traffic will be had (I'm talking in a web oriented use here).




Post #82198
Posted Tuesday, October 7, 2003 8:12 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 8:16 AM
Points: 1,035, Visits: 410
quote:
It is very nice to see a viewpoint that is different from what all the pundits are touting. This is a very good article but it does miss a couple points.XML is more transportable because everyone doesn't have to agree on a single way to structure the data. If I get three XML feeds from three different sources and they contain the same data in a different format I can use XSLT to restructure them into the format my application expects. It's easier and faster (read as: more cost effective) to write a transformation when we get a new data feed than it is to write a bunch of procedural code and recompile my application.In regard to the "flawed" OO paradigm, the real flaw is the people that don't know how to convert an object model to a data model. The people designing databases that can't fit an OO application are the same ones that can't design a DB for a procedural app. They are also the ones that blame the database server when something doesn't work.OO and relational work perfectly well together. Use OO code to get the data in a structured format and then put it in a relational database in an appropriate format. You then have good data that can be used in the OO world and is great for set-based reporting.BTW, OO is certainly not the end-all be-all of software development. Procedural programming is far from dead and appropriate in many areas (Event-driven GUIs for example).The Information Technology arena has no room for extremists. Use the right paradigm/methodology/tool for the job.Bryant E. Byrd, MCDBASr. SQL Server DBA/Systems AnalystIntellithought, Inc.bbyrd@intellithought.com
Thank you for your reply. In indicating that OO is "flawed" I did not intend to mean that it should be abandoned. However, the point still stands that OO is not based on sound, scientific principles. The relational model of data IS. Yet it is the OO pundits who seem to cry the loudest that there must be something wrong with the relational model and they are constantly touting something "new and improved" to replace it. I will not deny that the relational model MAY someday be replaced by something better, but that day hasn't arrived yet. By the way, I am well aware of the "benefit" of being a standard and address the issue in the article. XML is far from being a true standard and even if it becomes so, it will be a poor standard. I fully understand the history and impetus behind XML. I have put quite a bit of research into the subject over the past two years. What I learned is that XML was devised by those who have no understanding of data management fundamentals and their writings continue to prove it. XML as a data transport may be useful (if bloated and inefficient) but that is not the main problem I see with it. As I said in the article, the main problem is ignorant programmers who seem dead-set to take a 30 year leap backwards to use XML for data management. This is just plain stupid and there is really no excuse for it.You might call me an extremist. I suppose I have to plead guilty as charged. I believe that we, as data management professionals (not professional knob turners of any specific platform) have an absolute responsibiltiy to ensure the integrity of our company's data. I do not believe that there is room for compromise here. If at any point in the life of that data, integrity is compromised, you can't just magically impose it later. Further, I firmly believe that unless we keep our eye on the fundamentals of data management we will continue to waste vast amounts of money on that vendor merry-go-round. I, for one, am tired of being promised the world and delivered a stinking swamp!



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

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 #82199
Posted Tuesday, October 7, 2003 8:34 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, Visits: 7
quote:

I also find it somewhat amusing that people still believe relational databases are inheriently better than hierarchal. There's no one solution fits all. Have the OO arguements taught these people nothing?



Quite right, there are different solutions for different things. The relational model is the solution for database management. It was invented because the hierarchical model is flawed, not as a complement to it. The relational model is set-theory and logic applied to database management, what is xml?

quote:

Self describing data is a joke. Even in relational database (column name) it's a joke. The end result is whoever is using the data needs to understand the data. Let's not make this more complex than it needs to be.



A relational database management system is not concerned with the names of columns, not more than that they are a part of the constraints that describes the database. The complete set of constraints for all tables in a database is what describes the database and is the only thing the DBMS can use to 'understand' the data. How does xml handle this?

--
Chris Hedgate @ Apptus Technologies (http://www.apptus.se)
http://www.sql.nu




--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
Post #82200
Posted Tuesday, October 7, 2003 8:42 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 4, 2007 10:09 AM
Points: 198, Visits: 2
this author has made a compelling argument and one I am excited to see written. I think it's time more people challenged the conventional wisdom that XML should be applied wherever possible, whether it adds value or not.

I think like most technologies one must separate the good from the hype. With XML the "hype" slice of the pie seems to be proporationally bigger than with most technologies and I think a lot of people implementing it are doing it for the wrong reasons.

Case in point - I have customers who call me to ask why I am not storing relational data in XML format in a SQL Server database for my SQLAudit product. Rather than try to reinvent the theory of a relational database I attempt to glean the source of the questiion and turn it around - "Why *would* I store relational data in XML format in SQL Server?" and I just get silence. In one case the answer was that Yukon was going to offer an XML datatype and it would "improve performance" ??? the source of these queries usually are traced back to some software vendors trying to jump on the XML hype bandwagon and leverage XML "buzzword" purely for marketing purposes. They interact with customers and put the XML bug in their brain and the next thing you know you are defending proper database design against designs that violate almost every basic rule of relational database modeling. Is it XML's fault that it's being used improperly - no - but it's up to people like this author to clarify it's proper role in the universe and point out that it isn't a panacea and often is the wrong choice.

good job!

Brian Lockwood
LockwoodTech Software - value added SQL tools
http://www.lockwoodtech.com



Brian Lockwood
President
ApexSQL - SQL Developer Essentials

http://www.apexsql.com/blog

Stand up for an Independent SQL Community - be Informed
Post #82201
Posted Tuesday, October 7, 2003 8:43 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, June 26, 2012 12:15 PM
Points: 48, Visits: 9
>The Information Technology arena has no room for extremists. Use the right paradigm/methodology/tool for the job.

Finally somebody with the right idea.
Just another tool for the old tool box.

Like using pliers to remove a torx screw when I have a torx screw driver, and I just didn’t know what it was for. Darn if don’t always forget the hammer.

Ignorance != bliss






Post #82202
Posted Tuesday, October 7, 2003 8:44 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, March 15, 2005 2:29 AM
Points: 76, Visits: 1
ok, alot of comments here and no one is 100% correct as this is a subjective issue.

The article was titled "Is XML the Answer...". The answer to what? I agree that XML is not the answer to a large enterprise data store. A good RDMS is whats needed here, SQL Server, Oracle, MyPhp, whatever... A large dataset is always going to best off stored and MANAGED in a fully relational database server.

But XML is the answer to many problems and issues. One of the biggest is data transportation. XML has made this so much easier over the last 3-4 years. It is a standard and a standard that is going to stick. It may not be as strict a standard as we are used to, but a easy to use standard way of transporting data it is.

It also offers so much more, easy transformation for user display, easy parsing, human readability (For debuging, development), but its not the answer to everything and I dont thing anyone has ever said it is.

XML does not lend itself very well to data management, i dont think was ever intended to be used as such. It is purley a markup language for transporting data between systems.

Let it do what it was intended for and XML is fantastic!








Post #82203
Posted Tuesday, October 7, 2003 9:00 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, July 24, 2009 2:51 AM
Points: 2, Visits: 4
quote:

The relational model is set-theory and logic applied to database management, what is xml?



A simple solution for conveying meaninful information about simple entities and simple relationships. Like you say - different solutions for different things.

quote:

The complete set of constraints for all tables in a database is what describes the database and is the only thing the DBMS can use to 'understand' the data. How does xml handle this?



An XSD schema and the Document Object Model. Granted, a standard XML schema is not enough to control referential integrity and relationships in itself. However, if XML is being mapped onto an RDBMS (such as SQL Server 2000), a schema using the SQL namespace and processed by the SQLXML engine is more than adequate to 'understand' the data in the way you suggested.

(In fact you get two levels of schema, the XML-level schema AND the database schema (the former is generally born of the latter). That means that the data, relationships and integrity are validated both during code-execution by the SQLXML engine and during the standard database transaction. Bonus!)

quote:

We as developers and DBAs can do our part by not using these features and by continuing to request more important features and functionality, especially a better implementation of the relational model.



I'm not quite sure why we should be protesting through not using features when they can (and in my case have) been useful.. That seems like a political decision rather than a practical one. Can't we have both - data services features as well as improvements to the relational implementation? After all, data access is one of the roles of a DBMS.




Post #82204
Posted Tuesday, October 7, 2003 9:28 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, July 4, 2013 6:16 AM
Points: 11, Visits: 155
XML addresses two major needs: transferring data from one place to another and storing "sparse" data. The usefulness of XML in transferring data has been addressed well in the previous comments so I won't go into it.

But let's talk about storing "sparse" data. You have a sparse data situation when most of your records don't have actual data in them, i.e., they have a lot of missing fields. As an example, think about people's addresses. It used to be that a person's address referred to a street address, but now it could be an email address, or a web site address, or any number of different phone numbers. In my contacts list I have a whole bunch of people with just their street addresses and a whole bunch with just their email address. So the questiuon is how do I store this information economically. If I use an RDB one choice is to have a StreetAddress table and an EmailAddress table both related to NameTable. Some of the people won't have an EmailAddress record and some won't have a StreetAddress record. It's trivial to get a listing of people with street addresses and it's trivial to get a listing of people with email addresses. But what if I want a listing of everyone with the appropriate address shown? Then I have to start doing outer join queries which are always a mess to get right. If I throw in telephone numbers I just add to the mess. XML can solve the problem by providing a single Address document that is subdivided into StreetAddress elements (which in turn can be subdivided into street, city, state, postal code elements), EMailAddress elements (which using attributes might distinguish between business email and personal email) and Telephone elements (also divided possibly into home phone, work phone, cell phone, pager, etc.). If, for a particular person, some (or most) of the data is missing, then those elements are left out of the Address document. Nothing extraordinary has to happen to create my contact list. XSL and XQuery easily deal with the lack of data.

Addresses are just a simple example of this kind of situation. Think about what all the possibilities are to catalog a book (author names, available languages, editions, reprints, etc.) and imagine having to create an RDB that handles all the situations. It's possible but the schema will be incredibly complex. (Go look at the MODS XML schema being defined by the Library of Congress to see the gory details). It's these situations that XML does better. No one is ever going to produce an efficient XML implementation of an accounting system, but on the other hand there are clearly many situations where RDBs are too structured to provide an efficient repository mechanism.





Post #82205
Posted Tuesday, October 7, 2003 9:35 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 1:18 AM
Points: 5,956, Visits: 285
quote:

The Information Technology arena has no room for extremists. Use the right paradigm/methodology/tool for the job.


I guess that's what it's all about!!!
Every technique is fine for its' specific niche
nothing more and nothing less.

Btw, a truely relational database does not know such a thing as a field or a record. It's all about column and rows . To quote Joe Celko's usual rants on the MS newsgroups :

HUGE DIFFERENCE !!!!

Frank
http://www.insidesql.de


--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/
Post #82206
Posted Tuesday, October 7, 2003 9:37 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
Taking a step back, thanks for the article, dc -- I enjoyed it and the debate it has provoked. I certainly agree with your views on the overhyping and misapplication of technologies, although I think you've given an unbalanced description of XML to help make your case.

However, one comment in your follow-up really piques my curiosity.

>>XML is far from being a true standard.

Could you elaborate on this? I think this could be worthy of a separate article.




Post #82207
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse