Re: The good, the bad, and the ugly
Date: Mon, 27 Sep 2004 09:04:28 +0200
Message-ID: <4157bb7d$0$48933$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
...
> Laconic2 wrote:
>
>>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 think it's a pretty good way of exchanging >>data, too, even if it isn't very concise. ...
>>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
>
> The real issue is not the format, but the fact that they can persist XML
> documents without the overhead of a traditional RDBMS.
This can be done with any document format, even msword.doc or rtf.
XML had some advantages over other formats to start with which
brought it acceptance:
simplicity (as compared to SGML), familiarity to HTML, easy to read,
early managed standardisation. Now the broad acceptance in itself is
a major reason to use it.
> 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.
Now and later. IMO sharing and complexity are the mean reason to put data *as* *such* under management. Migrating it later is messy, and very expensive, mostly boils down to re-archituring the lot. So yes, if you are sure you are *not* going to share data later on, and if it (in this case the inter-document structure) is simple, skip the management.
> 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?
Not if this is the only service you are providing, IOW if you can afford dedication.
> 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.
Repeating myself: Sharing and complexity. If neither are there, I see no need.
> 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.
Yes. This was one of the XML design goals: easily readable for both programs and humans.
> 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?
Normalizing adds complexity initially and gives you flexibility later on. No need to normalize if you can garantee that there is only one program reading and writing. Just encapsulate the kludge.
But sharing is out, and your data only lives as long as your application.
>>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
Or just a cooler bag for a picknick.
BTW there is a perl module for persistence called Freeze-Thaw.
Received on Mon Sep 27 2004 - 09:04:28 CEST