[
Lists Home |
Date Index |
Thread Index
]
<quote>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.
</quote>
why do we always say 12 rules? like all good mathematicians codd counted
from 0. [0,12] is 13 numbers or rules in this case.
http://www.cis.ohio-state.edu/~sgomori/570/coddsrules.html
and while i'm on it, there's 5 normal forms. 3rd is easy to get to, but
5th is by a country mile better for storage and manipulation.
:)
rick
> On Tue, 2003-08-26 at 05:11, Michael Kay wrote:
> >
> > 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
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
