On 06/01/2012 00:14, Len Bullard wrote:
8044FBBA608F4BAEACD54B9453165FD9@LenBullardPro" type="cite">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 |