Lists Home |
Date Index |
> On May 19, 2004, at 10:37 AM, Dare Obasanjo wrote:
> > Hierarchical databases failed for a reason.
> Just to be pedantic, the hierarchical model failed, hierarchical
> databases are still chugging along. IMS (a hierarchical DBMS that is
> the meanest, nastiest, ugliest mainframe dinosaur) still quietly
> manages an awfully big chunk of the world's data: "More than
> ninety-percent of the Fortune 1000 companies use IMS. IMS serves 200
> million end users, managing over 15 billion Gigabytes of production
> data and processing over 50 billion transactions every day."
. . . if it ain't broke, don't fix it . . .
I used hierarchical databases in the 80's and even into the 90's, but had
nowhere the capabilites I do with XML. I think this was primarily due to
the fact that a schema had to be defined apriori, and once a schema was set
and data loaded, to make changes you had to unload the data (all of it, not
just few affected tables), alter the schema and reload. For large systems
(like the telecom billing systems I was building with 20-100M new records
added everyday), making a schema change became a 2-3 day downtime event to
unload/reload data (we now live in a real time world). All the relational
model did was break up this single monolithic chunk of data into separately
managed tables, so now part of the databse could be down instead of the
whole thing... but the structures are still pre-defined, making them less
than ideal for eXtreme Programming developments.
XML is a true Information Domain. Both the schema (e.g. meta data, tags,
elements attributes) and the data are dynamic (I am NOT talking about XSD
schemas). One to one relationships are extended to one to many
realtionships by simply inserting another instance of the tag into an XML
document vs. a hierachical or relational model which requires redesign, with
a new part-of or intersection table, with nothing but foreign key
Business requirements change, and with that change come changes to the
Information Model. XML is the only representation I have used that is
flexible enough to extend itself without a need for a database redesign,
which in turn generally means database downtime to make the changes and
convert existing data structures. Of course, that is only if you are using
a native XML database, and not building XML-Relational mapping layers into
an RDBMS, which removes all the flexibility just stated.
http://www.xpriori.com/ - XML Persistence for eXtreme Programmers