What's the simplest way to set up a relationional database with tree
data? I'm more interested in simplicity vs speed.

Suppose you have a tree database with 3 levels. Company-Division-
Manager. Like this:

IBM
Div-A
Jones
Smith
Div-B
Smith
Microsoft
Div-A
Johnson
Div-B
Jones
Smith

I was going to try something like this:

Company Table
ID Company Data
1 IBM -
2 Microsoft -

Division Table
ID Division Data
3 Div-A -
4 Div-B -
5 Div-A -
6 Div-B -

Manager Table
ID Manager Data
7 Jones -
8 Smith -
9 Smith -
10 Johnson -
11 Jones -
12 Smith -

ID Table
ID Parent
1 *
2 *
3 1
4 1
5 2
6 2
7 3
8 3
9 4
10 5
11 6
12 6

Any help would be appreciated!

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 10:10*am, cr113 <cr... (AT) hotmail (DOT) com> wrote:
You're on the right track in realizing that you have a tradeoff to
make (simplicity vs. speed). However, there are a number of other
design considerations that will also inform the final product.

What are your needs in terms of flexibility, for instance? Is it the
case that the specific "hierarchy" you've outlined is the only one you
need to support?

Re: other design considerations, Graeme Simsion has what I consider to
be a good article here:
http://www.tdan.com/view-articles/5100

People will be able to guide you better if you can expand more on what
criteria are important to you.

TroyK

On Feb 8, 11:42*am, TroyK <cs_tr... (AT) juno (DOT) com> wrote:
Here are some specifics: I'm using Access. There will only be a few
thousand records maximum in any table. Around 4-6 fields in each
table. Very few concurrent users. The users need to be able to add/
edit/delete any of the nodes in the tree. There are 4 levels in the
tree. Expanding the previous example it would look something like
this:

Company
Division
Manager
Employee