[
Lists Home |
Date Index |
Thread Index
]
>
> I am saying I have not seen a proof that XML supports, or can
> be engineered to support, the Relational Model.
Of course XML doesn't support the relational model. The relational model
consists of structures and operations on those structures; XML doesn't
define any operations on its structures.
And what does "support" mean anyway? What does it mean to "support" a
model?
>
> 1) One reason the Relational Model was developed was to
> reduce coding and design efforts required throughout the
> application life cycle, while offering as much flexibility
> and reliability as possible.
You're guessing. At any rate, that's not how Codd described his goals in
his 1970 paper.
> 2) Data based applications developed using the Relational
> Model, which are well engineered and designed, will feature
> lower cost over time with greater flexibility.
Evidence please? (Lower than what, anyway? Lower than badly engineered
and designed systems?)
> One rule of
> thumb is that maintenance costs will be less than 1/100th of
> the development (or all pre-production costs).
Are you serious? You are telling me that a system that costs $10m to
develop will have a lifetime maintenance cost of $100K?
> 3) XML applications are all data based applications, whether
> you call documents data as a structured formatted element, or
> data as a set or group of elements. IE there are no XML
> applications that do not contain or process data elements.
I find it hard under that definition to imagine any IT applications that
are not data based. I think you are fudging terms. Not all "data-based"
applications are "database" applications.
> 4) Rigorous, scientific proofs exist, and are easily found,
> for adherence to the Relational Model (RM). Saying that
> something supports SQL does not say it can implement or
> adhere to RM, because SQL support does not require RM
> compliance or support per se.
Yes, Codd's 12 rules are reasonably objective as these things go. The
trouble is, when you try to use them, they tell you that every real
system is not relational, which isn't very helpful.
You seem to be confusing the existence of rigorous tests that show
whether a system is relational with the existence of rigorous proofs
that show that relational systems deliver specific engineering benefits.
The latter are sadly lacking - we have to rely on anecdotal evidence for
such judgements.
> 5) I have seen nothing better than RM for improving software
> application reliability, flexibility, maintainability and
> lowering software system costs overall. If something better
> exists, as a methodology with scientific proofs, I would
> dearly like to see it.
You're telling me that you trust your own unscientific anecdotal
observations to show the merits of the relatational model, and you won't
accept anecdotal evidence that other things might be better? Sounds a
bit biased to me...
Remember that Codd himself spent a lot of time and energy trying to
improve the original relational model, in particular by enhancing its
semantic richness.
Your real mistake is in assuming that the world is one-dimensional, that
there is only one measure of goodness. Different technologies are good
at different things, there are a range of metrics that you can apply to
them, and they give different answers.
>
> So. My point is that I have not seen a rigorous, scientific
> proof for RM via XML or any XML tool set.
You're not being clear. What assertion do you want to see proved?
>
> This leads me to conclude that a very high probability,
> almost a certainty, exists that any XML application will
> endure the specific issues which RM was designed to resolve.
> Especially large scale data based applications featuring
> significant or exclusive XML usage.
Sure. It's highly likely that if you measure a system by the things that
the RM does well, then anything else will not do as well. It's also easy
to find things that the RM does badly, which other technologies do far
better.
A couple of years ago I saw some people trying to do data integration of
heterogeneous databases entirely using direct SQL mappings of one to the
other. It was awful. Every time any of the databases changed, the whole
thing broke. XML as an intermediate representation of the data model
would have worked far better. The reasons for this are well known - SQL
simply doesn't have enough semantic richness, enough power of
abstraction, enough ability to handle complexity. Minor changes like
allowing a customer to have more than one address require a complete
redesign of the data structures.
(I saw another system that did daily data interchange, between two
different companies, in the form of a binary image of a SQL server
database. Neither company was able to make any changes to its software
configuration because of fears that the transfer would stop working.
This is the kind of nonsense you get when you pursue the "it's
relational so it must be good" line of reasoning.)
>
> As a Software Engineer, someone who majored in Computer
> Science, I have grave concerns about applications already
> deployed, or in development, that make significant usage of XML.
>
Then you should have even graver concerns about any system that does
data interchange using proprietary ASCII files, which means almost every
real IT system in live use.
The challenge in large scale IT systems is to manage heterogeneity, to
keep the components well isolated from each other so that they can
evolve independently, generally to achieve loose coupling. XML is
ideally suited as the technology to use at the interface between the
components. The relational model works well for managing the local data
within each component, so long as it is not too complex, but as an
integration technology, it is hopelessly flawed.
Michael Kay
|
