[Exist-open] Recommendations for DB structure

[Gil T. <Gil...@we...>]

Does anybody know of any best practices for the best DB structure? I am
talking about a fairly regular "database-like" application:

=20

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

Issues,=20

Events, and=20

Tasks (...many fields).

=20

Also each Project is managed by a=20

Person (...many fields).

=20

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.

=20

(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)

=20

#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.

=20

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"

=20

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? :-)

=20

Thanks,

Gil Tayar

WebCollage

Chief Technology Officer

Business: +972 (3) 766 1806

Mobile:    +972 (54) 634 4457

=20