[
Lists Home |
Date Index |
Thread Index
]
From: "Chiusano Joseph"
> > > etc. (Possibly at this point you add in database constraints that
didn't
> > > previously exist, turn certain fields non-null, etc.)
> >
> > Sounds like you are using a relational database to store your XML. Talk
> > about an impedance mismatch. Why even bother with XML in the first
place if
> > you are shredding it or clobbing it?
>
> Perhaps because you have a system based on a relational database that
> has been in use for quite some time, and are using XML to exchange
> information with some or all of your trading partners - and you may not
> be able to justify ripping and replacing your relational system simply
> because an XML database is "better data management technology".
>
I hear what you are saying, Joe. In fact, I hear it a lot, but consider it
the normal rhetoric.
If that was a real reason, we wouldn't have relational databases today as in
the 80's we could have just continued to use our network and hierarchical
databases (just trying to follow your logic), upon which all our systems
were already built and running just fine (except they were hard to expand,
similar to the problems with relational databases and mature applications -
I am seeing a theme here). There are still MANY applications written on top
of IMS, or Dec RDBMS, or even VSAM. Does that mean we write new stuff on top
of that old technology?
So in the 80's, those with foresight said, yeah, I can do this the old way,
or I can do it the new way, and those that jumped on the bandwagon early had
a competitive advantage. In the 90's I converted my share of hierarchical
database applications to relational technology, because the time to
unload/change the schema/reload took more time than phone company billing
systems could be down (we are talking days here). Now everybody uses
relational databases, and those with foresight say "there is a better,
faster, easier way to do this". But most people are sheep, and do what they
know.
Fortunately, many of the regular contributors to this group know XML
technologies quite well (and I am thankful for the though provoking
discussion), but they still sprinkle their comments with "I know I should
do it different, but that is how I think, or that is what I know". With
XML, I don't try to convert applications, but wrap them into services, and
develop new stuff in the new paradigm, using ALL the new tools.
The original discussion was centered on all the layers of XML technology
(and options) used to do syntactic and semantic validations, and I believe
what everyone is missing from their XML stack is a native persistence
mechanism that does not require tons of glue code and O-R mappings just to
store the stuff. How many classes do you have to get data in/out of a
relational database, and convert it to XML or to your business objects? If
you could remove those from your code base, would it not improve quality,
shorten time to market, and dump the code everyone hates to write anyway?
Plus all the DDL your DBA writes, and normalization, and indexing, and
tuning SQL queries . . .
I will forgo the dis-assembling you car every night analogy that some folks
make, but the fact is: if you have to round-trip your XML to a client in
order to query, validate and or execute from it, then you will never be able
to scale (why do you think stored procedures were invented?)
So you have existing legacy systems built on relational DB's, and you have
already paid the tens of thousands of dollars per CPU for your Oracle or DB2
licenses. Let them run on into the future. The cost of the infrastructure
is miniscule to the overall lifecycle costs of an application. So quit
looking in the rear view mirror and start driving toward a complete
application solutions stack that is based on XML end-to-end, with little or
no impedance mis-matches along the way.
A very opinionated:
Owen
http://www.xpriori.com/developers/html/downloads.html
full disclosure: I am an independent consultant who provides services to
Xpriori as well as a number of other companies.
|
