Re: The good, the bad, and the ugly

"Laconic2" <laconic2_at_comcast.net> wrote in message news:042dnV7g9uRc3cncRVn-hg_at_comcast.com...
> In one of the other discussions, XML was listed as one of the bad things
> perpetrated by the object oriented people.

Many OO folks have the same disdain for XML that RDBMS people do. It is not particularly OO. It is more that it plays nicely with OO while RDBMS's require SQL skills and 1NF'ing your data before storing, I mean persisting, it that makes XML a more attractive format for some purposes.

> And I've seen a lot of
> discussion in here about using XML instead of a DBMS.
>
> I've never had the opportunity to get up close and personal with XML. I
> went to a lecture on XML once, and my impression was... Neat! They've
> extended the concept of self-describing data to data in transit as well as
> data inside a DBMS. I'll confess that I never even thought of getting rid
> of the DBMS. After I've heard that idea, I'm puzzled.
>
> If I compare XML to something like comma separated values, I think that
XML
> is a good way of representing a wide variety of data.

Comparing XML to comma-separated is a good way to classify it. When people complain that it is bad for one thing or another, I ask why they didn't have similar complaints about comma-quote formats for data. It is certainly better to have more metadata rather than simply column header names.

> And I think it's a
> pretty good way of exchanging data, too, even if it isn't very concise.

Agreed.

I
> imagine that you can make it more concise by defining a record type, and
> then supplying a stream of records, but that's more XML than I really
know.
>
> But XML instead of DBMS? The mind boggles. You have to be able to
> represent data in order to manage it. You have to be able to exchange
data
> in order to manage it. And you have to be able to decode it. But that's
> just the beginning of data management. There's a whole lot more that a
DBMS
> has to do, and it seems to me that XML doesn't even begin to address all
the
> issues.

The real issue is not the format, but the fact that they can persist XML documents without the overhead of a traditional RDBMS. This gives developers much more flexibility than the big-and-bulky DBMS's. This is more of a return to the good old days that some folks have never left (I'm still a believer, for example) and that new developers are discovering. It has to do with where you partition your software and how much you want the RDBMS to do. If you are writing web services, then you are handling security with who is authorized to use your web service somewhere in front of the DBMS -- then does the DBMS really have to perform that function? Similarly for business rules, including entity relationships. If software is written to exclude all CRUD services outside of the services that the developers write related to a given "database" then why would the developers want to bother with the overhead of a DBMS.

Additionally, XML allows you to persist the data in a form closer to the way a person thinks about the entities -- permitting nested tables, for example. This aligns with the way people speak. The UML class diagram does not need to be normalized. Nor does the Java work with data structures within an application, so why have to bother with that nonsense (just kidding-ish) simply for the purpose of storing the data the way the RDBMS wants to see it?

>
> It would be like trying to put a capsule on the moon by using a baseball
> bat!

Or like buying a refrigerator-freezer unit for your ice cream when it would not make sense to spend the time & money to build a walk-in freezer in your house. smiles. --dawn Received on Mon Sep 27 2004 - 06:52:45 CEST