Does anybody know of any best practices for the best DB structure? I am
talking about a fairly regular "database-like" application:
Clients (with many fields like name, phone #, ...) include a list of=20
Projects (each project, again with many fields) which include a list of=20
Tasks (...many fields).
Also each Project is managed by a=20
Person (...many fields).
The two extreme DB structures I can think of are:
1. Put them all in one big XML document, where each "include"
relation is a hierarchy in the XML, and where a "managed by" relation is
done using IDs and IDREFs.
2. Each object is its own separate document, and the relations are
managed using IDs and IDREFs.
(where obviously, we can have middle cases such as each client and
project being in a separate XML document, but the Issues, events, and
tasks are in the "Project XML" embedded in the XML hierarchy)
#2 also raises the issue of in which collection to put them. I can,
again, think of three main alternatives:
1. One big collection of all XML documents.
2. Put each XML document in a collection based on its structure.
3. If Projects include Issues, then the issue document is in a
sub-collection related to the project.
Obviously, there are about 100 variations to the above. I believe there
are three main criterias to evaluate each variation:
1. Query performance
2. Update performance
3. "Maintainability" and plain "Esthetics"
So can somebody help me here - what would you do? Is there a document on
the net somewhere that can help? Does it matter at all? :-)
Chief Technology Officer
Business: +972 (3) 766 1806
Mobile: +972 (54) 634 4457