[
Lists Home |
Date Index |
Thread Index
]
On May 28, 2004, at 10:52 AM, David Megginson wrote:
>
> I'd suggest a slightly different focus: the physical model is private
> while the logical model is public. XML is designed to handle the
> public, logical part so that people can share information without
> being forced to use the same physical models.
>
> Date's speech rants not against XML itself but against XML encroaching
> on the physical side. Granted, he doesn't like SQL much either, but
> he might be right about XML, unless object-oriented and XML databases
> are performing and scaling a lot better than they were the last time I
> looked.
>
I'm sortof sorry to perpetuate the logical/physical terminology outside
the world of relational modeling where it is reasonably well defined,
i.e:
- Conceptual models are of business concepts and relationships, e.g.
products, customers, invoices and are the domain of business analysts
- Logical models map those concepts onto relations, types, and tuples
(or tables, columns, rows, if you prefer) and are the domain of
database designers/programmers
- Physical models map those onto machines, files, partitions, indexes,
etc. and are the domain of DBAs
My argument is basically that XML allows you to munge these all into a
conceptually messy but pragmatically appealing whole: An invoice
(conceptual) can be modeled directly with an XML schema (logical) and
manipulated as an XML instance in a text file, RDBMS CLOB, NDXB entry,
DOM tree, SAX event stream, whatever. So, yes people can share
information because it is all "XML" irrespective of the
implementation-level representation as a file, DBMS record, event
stream, etc. That's not quite the same as the relational
logical-physical mapping, because in XML that's a completely mechanical
process of parsing/serializing, and the relational world it requires
human intelligence and deep expertise to do well. As Date is fond of
reminding us, both are in short supply.
So, XML succeeds for the familiar 80:20 reason -- it handles (well
enough) a lot of familiar situations such as document-driven business
processes with few impedance mismatches between the conceptual/end-user
level to the physical/implementation-level technologies without
demanding the scarce skills of effectively normalizing conceptual
models into relations, implementing DBMS that efficiently support N-way
joins as N gets large, and hiding all this implementation detail from
the conceptual and logical layers. There's certainly a cost -- I'm not
going to be the Anti-Date and say that XML is all you ever need, just
that there are plenty of cases where munging the
conceptual/logical/implementation layers into the single abstraction of
an XML instance is very practical.
I'm not sure what is meant by "XML encroaching on the physical side" or
"he might be right about XML, unless object-oriented and XML databases
are performing and scaling a lot better than they were the last time I
looked". It seems to me that a lot of the demand for XML is driven by
the very practical challenges of modeling relatively unstructured
information within the relational paradigm in a way that allows decent
performance and scalability on existing RDBMS products. I have obvious
Day Job biases here, but there are real performance benefits possible
from XML databases (or, to be fair, native XML CLOB types in an RDBMS)
that basically come from avoiding joins. Date is certainly right that
the "assembling a car from its components" metaphor conflates the
logical and physical levels, but AFAIK the simple fact is that existing
(relatively pure) RDBMS technologies don't support the distinction very
well, at least for hierarchical and ordered data such as XML. All the
benchmarks I know about that compare a native XML implementation to a
normalized relational implementation show that the more complex the
hierarchy (i.e., the more joins necessary to reconstruct the conceptual
model), the slower the pure RDBMS approach is compared to the pure XML
approach. The question in my mind is whether we will bridge the
logical-implementation gap by better RDBMS that physically maintain the
car intact while logically treating it as a collection of parts, or
whether something [perhaps like Childs' stuff? ] that unifies the
logical - physical and relational - hierarchical conceptions will be a
better way forward.
|
