Forum Discussion
IvanWeiss
6 years agoQrew Captain
Evan, thanks for the SUPER DETAILED response again! So here is my challenge.... I have several different clients I need to maintain the relationship for. Not all of them have the same structure level.
So my concern with the separate table is one of my client uses RVP and DM as the levels. Another one of my clients use SVP, Vice President of Operations, and DM as the three levels (they have an extra one).
So in a separate table approach could it intelligently understand this or does that push me to the self related table approach?
If I go with the self table relationship.... I think I would relate "down" stream correct? So on the contact I would have a one to many relationship to contacts and that relationship would be direct reports and that would be the level down (DM's in the first example above)
------------------------------
Ivan Weiss
------------------------------
So my concern with the separate table is one of my client uses RVP and DM as the levels. Another one of my clients use SVP, Vice President of Operations, and DM as the three levels (they have an extra one).
So in a separate table approach could it intelligently understand this or does that push me to the self related table approach?
If I go with the self table relationship.... I think I would relate "down" stream correct? So on the contact I would have a one to many relationship to contacts and that relationship would be direct reports and that would be the level down (DM's in the first example above)
------------------------------
Ivan Weiss
------------------------------
EvanWestbrook
6 years agoQrew Cadet
Ivan,
I'm glad you appreciated the details. I get a little excited about data stuff sometimes.
To answer your question: yes, the separate table approach would handle varying structure levels for different companies.
If we think about this on a really high abstraction level, this use case is just describing how entities are related to other entities (sounds like a database!) With corporate management structures, we're tracking how employees are related to other employees. Specifically, who reports to whom. Since this doesn't require an employee's title (at least in the eyes of the database,) we can handle the corporate structures of different organizations in the same table. Said another way, the corporate hierarchy of Company A and B are implicit in the "Contact Hierarchy" table.
Here's a quick example:
------------------------------
Evan Westbrook
PRIME Developer
Harder Mechanical Contractors Inc.
Portland OR
------------------------------
I'm glad you appreciated the details. I get a little excited about data stuff sometimes.
To answer your question: yes, the separate table approach would handle varying structure levels for different companies.
If we think about this on a really high abstraction level, this use case is just describing how entities are related to other entities (sounds like a database!) With corporate management structures, we're tracking how employees are related to other employees. Specifically, who reports to whom. Since this doesn't require an employee's title (at least in the eyes of the database,) we can handle the corporate structures of different organizations in the same table. Said another way, the corporate hierarchy of Company A and B are implicit in the "Contact Hierarchy" table.
Here's a quick example:
- Company A:
- Structure:
- RVPs report to VPs
- Contacts and Title:
- Diane (VP)
- Todd (RVP)
- Structure:
- Company B
- Structure:
- DMs report to VPs
- Contacts and Title:
- Caroline (VP)
- Bo (DM)
- Structure:
- Record 1
- Supervisor: Diane
- Direct Report: Todd
- Record 2
- Supervisor: Caroline
- Direct Report: Bo
------------------------------
Evan Westbrook
PRIME Developer
Harder Mechanical Contractors Inc.
Portland OR
------------------------------