- From: Michael Kay <mike@s...>
- To: xml-dev@l...
- Date: Fri, 06 Jan 2012 07:29:03 +0000
On 06/01/2012 00:14, Len Bullard wrote:
8044FBBA608F4BAEACD54B9453165FD9@LenBullardPro"
type="cite">
When
building XML systems, how do you
choose the best granularity for storing and retrieving
fragments?
Not
entirely sure what you mean by a "fragment": is your
question "how much data goes in one XML document"? That is
indeed a difficult question. The decision tends to be made
for operational reasons rather than pure data modelling
reasons, and is thus an example of how XML fails to make a
clear distinction between logical and physical design in the
way that database people have been advocating for decades.
Many XML databases work best when you have lots of small
documents; a few work well when you have one giant
all-embracing document. That's a factor that can't be
ignored in your design, even though one would like to.
Another factor is that the document is often the unit of
validation. Cross-document validation is generally awkward.
Similarly, the fact that documents are the unit of
interchange affects the decision (sometimes it rightly
dominates the decision).
There are many applications where "one document per business
object" works well: e.g. in a system managing data about
hotels, one document per hotel. But where do you put the
information about room availability? One document per hotel
per night? It starts to become very arbitrary. That's one
reason why there will always be a need for transformations.
Michael Kay
Saxonica
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
Cart
