[
Lists Home |
Date Index |
Thread Index
]
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
</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).
| 