[
Lists Home |
Date Index |
Thread Index
]
At 10:30 AM 9/11/2003, Jonathan Robie wrote:
>Jason, you are really asking what the optimum way is to store some data
>for a particular task. I don't know what needs to be optimized until I
>know more about what you are doing with this data. Here are some questions
>that might be helpful for a start:
>
>- What kind of data is this? Are there logical connections that would be
>lost if the data were divided up into smaller "chunks"?
>- Are you creating many different kinds of XML documents from the same
>data, or do you retrieve it in the same form it was stored?
>- How many users are anticipated? What kind of turnaround time is needed?
>For what kinds of requests?
>- How is the data updated?
If you want to store XML documents intact, the document order matters to
you, and the entire document must be treated as one logical whole, then a
native XML storage system may be what you need. For a document of the size
you mention, here are some important questions:
1. How often is it updated, and at what level of granularity? Updates of
large single documents are slow on many native-XML systems. Updates of
smaller documents are generally much faster.
2. Do you need the entire logical structure of the single document? Is
order significant? If so, you may need to store the entire document as a
whole. If your system does not support this well for documents of the size
you anticipate ... you might have a problem.
3. In the stored form, are you going to be normalizing the data to make
updates more manageable? That has real ramifications for the structure of
the data....
Also, what CMS system are you using?
Jonathan
|
