[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-dev
Subject: RE: [xml-dev] Better design: "flatter is better" or "nesting i s better" ?
From: "Bullard, Claude L (Len)" <len.bullard () intergraph ! com>
Date: 2005-09-30 18:56:52
Message-ID: 15725CF6AFE2F34DB8A5B4770B7334EE072074D5 () hq1 ! ingr-corp ! com
[Download RAW message or body]
One may not know the source. One may not know the target. Or one may be
in a
contractual situation (aka, the meta-environment constraints) that dictate
that the
system only sends or receives in the context of the 'schema current on
delivery
of system'. That proves to be just a negotiation ploy though, since in
principle
and in fact, it is very easy to add fields to relational system (the
dominant ones
today) **as long as there are no semantic implications** (aka, running
code).
The contract language serves to retard attempts to push the schema to
extremes that result in massive redesign and redeployment. The closer one
gets to 'COTS' and the further one gets from "demos, prototypes and one
offs", the more one wants to be conservative. It isn't to be a Luddite,
but
to ensure that the system will actually get deployed with running, certified
and well-understood components.
It is generally true that flatter is better, IMO, and that when designing
for large or
general markets, stay close to existing widely deployed technologies if you
want
to get the standard deployed in real world systems within the buy cycle for
that
market. This is simple state transition common sense: if the next state is
dependent on the last state with absolute known probabilities (first order
markov), you can predict the future and know the past with certainty.
Unfortunately, one seldom finds systems of that type in a dynamic
environment.
Past one or two transitions, and it all becomes prophecy or intention.
Beggaring implementation technologies through schema design is a bad idea.
That is too often the result of future-proofing.
len
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
</Quote>
Part 2: Design your XML to be flat, with direct mappings from XML to
(relational) database tables.
</Quote>
Sometimes one is also using XML without any notion of a specific database
type or database design - for example, for a data exchange in which XML is
used as an intermediary exchange format to bridge between XML vocabularies.
In such cases, all one knows is the "source" vocabulary and the "target"
vocabulary, not any storage mechanism on either end. So in that case, it's a
choice involving other factors (such as design preference).
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>One
may not know the source. One may not know the target. Or one
may be in a </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>contractual situation (aka, the meta-environment constraints) that
dictate that the </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>system
only sends or receives in the context of the 'schema current on delivery
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>of
system'. That proves to be just a negotiation ploy though, since in
principle </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>and in
fact, it is very easy to add fields to relational system (the dominant ones
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>today)
**as long as there are no semantic implications** (aka, running code).
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>The
contract language serves to retard attempts to push the schema to
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>extremes that result in massive redesign and redeployment. The
closer one </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>gets
to 'COTS' and the further one gets from "demos, prototypes and one
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>offs",
the more one wants to be conservative. It isn't to be a Luddite, but
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>to
ensure that the system will actually get deployed with running, certified
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>and
well-understood components.</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>It is
generally true that flatter is better, IMO, and that when designing for large or
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>general markets, stay close to existing widely deployed technologies if
you want </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>to get
the standard deployed in real world systems within the buy cycle for that
</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>market. This is simple state transition common sense: if the next
state is </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>dependent on the last state with absolute known probabilities (first
order </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>markov), you can predict the future and know the past with
certainty. <BR>Unfortunately, one seldom finds systems of that type in a
dynamic environment. </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>Past
one or two transitions, and it all becomes prophecy or
intention.</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>Beggaring implementation technologies through schema design is a bad
idea. </FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff size=2>That
is too often the result of future-proofing.</FONT></SPAN></DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=974554518-30092005><FONT face=Arial color=#0000ff
size=2>len</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2><BR><B>From:</B> Chiusano Joseph
[mailto:chiusano_joseph@bah.com]<BR></FONT></DIV>
<DIV dir=ltr align=left>
<DIV align=left><FONT size=2><SPAN class=007373718-30092005>
<DIV align=left><FONT face=Arial size=2><SPAN
class=007373718-30092005></Quote></SPAN></FONT></DIV></SPAN></FONT><FONT
size=+0><FONT face=Arial><FONT size=2>Part 2:</FONT><FONT size=2> Design your
XML to be flat, with direct mappings from XML to (relational) database
tables.</FONT></FONT></FONT></DIV></DIV>
<DIV><FONT size=2>
<DIV align=left><FONT face=Arial size=2><SPAN
class=007373718-30092005></Quote></SPAN></FONT></DIV>
<DIV align=left><FONT face=Arial size=2><SPAN
class=007373718-30092005></SPAN></FONT> </DIV>
<DIV align=left><FONT face=Arial size=2><SPAN
class=007373718-30092005>Sometimes one is also using XML without any notion of
a specific database type or database design - for example, for a data exchange
in which XML is used as an intermediary exchange format to bridge between XML
vocabularies. In such cases, all one knows is the "source" vocabulary and the
"target" vocabulary, not any storage mechanism on either end. So in that
case, it's a choice involving other factors (such as design
preference).</SPAN></FONT></DIV>
<DIV align=left><FONT face=Arial></FONT></FONT><SPAN
class=224572115-30092005><FONT
size=2></FONT></SPAN> </DIV></DIV></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic