对于需要多层次映射的数据,如何设计数据库?
How to design a database for data which needs to be mapped at multiple levels?
我有以下数据库实体:
- 组织 - 顶级
- 项目 - 组织可以有很多项目。
- 团队负责人 - 项目可以有多个团队负责人。
我已经有以下这些数据库 tables:
- 组织
- orgnization_id
- (其他属性)
- organization_projects
- organization_id(来自组织 table)
- project_id
- (其他属性)
- projects_team_leads
- organization_project_id(来自 organization_projects table)
- team_lead_id(这是员工的 id table)
现在,我想在这里再添加一个名为承包商的实体。契约者属性如下:
- 一个团队负责人可以有多个承包商。在团队负责人和承包商之间的映射中会有某些关联的属性,例如 manage_start_date
- 一些信息还需要在承包商和项目之间建模。例如。承包商在“项目”级别的评级。
- 一些信息也需要在承包商和组织之间建模。例如。 “contract_duration”
另请注意,只有一名团队负责人可以管理项目内的承包商。
承包商也有全局信息,如姓名、dob 等,这些信息驻留在员工 table 中。但是,这个员工table在另一个微服务中。
当前任务是将承包商添加到具有项目和组织的服务中,并在不同级别(团队领导级别、项目级别和组织级别)添加必要的属性。
我正在考虑在每个级别设置单独的 table。例如
- organization_contractors
- organization_id
- contractor_id(来自不同微服务中的员工table)
- contract_duration
- project_contractors
- organization_contractor_id(来自 organization_contractors table)
- organization_project_id(来自 organization_projects table)
- 评分
- team_lead_contractors
- 项目_team_lead_id(来自project_team_leads table)
- contractor_project_id(来自 project_contractors table)
- manage_start_date
我对此唯一的疑虑是,在 team_lead_contractors table 中,可以从 project_team_lead_id 和 contractor_project_id 中推断出该项目。
与其他方法相比,这种方法的优缺点是什么?
如果我理解正确,...
- 有组织和承包商。
- 组织可能与承包商 A、B、C 和 D 签订了合同。
- 该组织中的一个项目可能与其中一些承包商相关,比如项目 P1 与 A、B 和 C 相关,而项目 P2 与 A 和 D 相关。
- 每个项目都有项目负责人。项目 P1 可能有潜在客户 PL1 和 PL2。
- 每个项目负责人都可能与所有或仅与部分项目承包商相关。 PL1可能与A和B有关,PL2可能与A和C有关。
如果您希望您的 DBMS 保证所有这些实体的数据一致性,我建议您使用复合键。
table organization
organization_no
...
table contractor
contractor_no
...
table organization_contractor
organization_no
contractor_no
...
PK (organization_no, contractor_no)
FK organization (organization_no)
FK contractor (contractor_no)
table organization_project
organization_no
project_no
...
PK (organization_no, project_no)
FK organization (organization_no)
table organization_project_contractor
organization_no
project_no
contractor_no
...
PK (organization_no, project_no, contractor_no)
FK organization_project (organization_no, project_no)
FK organization_contractor (organization_no, contractor_no)
table organization_project_lead
organization_no
project_no
lead_no
...
PK (organization_no, project_no, lead_no)
FK organization_project (organization_no, project_no)
table organization_project_lead_contractor
organization_no
project_no
lead_no
contractor_no
...
PK (organization_no, project_no, lead_no, contractor_no)
FK organization_project_lead (organization_no, project_no, lead_no)
FK organization_project_contractor (organization_no, project_no, contractor_no)
我有以下数据库实体:
- 组织 - 顶级
- 项目 - 组织可以有很多项目。
- 团队负责人 - 项目可以有多个团队负责人。
我已经有以下这些数据库 tables:
- 组织
- orgnization_id
- (其他属性)
- organization_projects
- organization_id(来自组织 table)
- project_id
- (其他属性)
- projects_team_leads
- organization_project_id(来自 organization_projects table)
- team_lead_id(这是员工的 id table)
现在,我想在这里再添加一个名为承包商的实体。契约者属性如下:
- 一个团队负责人可以有多个承包商。在团队负责人和承包商之间的映射中会有某些关联的属性,例如 manage_start_date
- 一些信息还需要在承包商和项目之间建模。例如。承包商在“项目”级别的评级。
- 一些信息也需要在承包商和组织之间建模。例如。 “contract_duration”
另请注意,只有一名团队负责人可以管理项目内的承包商。 承包商也有全局信息,如姓名、dob 等,这些信息驻留在员工 table 中。但是,这个员工table在另一个微服务中。
当前任务是将承包商添加到具有项目和组织的服务中,并在不同级别(团队领导级别、项目级别和组织级别)添加必要的属性。
我正在考虑在每个级别设置单独的 table。例如
- organization_contractors
- organization_id
- contractor_id(来自不同微服务中的员工table)
- contract_duration
- project_contractors
- organization_contractor_id(来自 organization_contractors table)
- organization_project_id(来自 organization_projects table)
- 评分
- team_lead_contractors
- 项目_team_lead_id(来自project_team_leads table)
- contractor_project_id(来自 project_contractors table)
- manage_start_date
我对此唯一的疑虑是,在 team_lead_contractors table 中,可以从 project_team_lead_id 和 contractor_project_id 中推断出该项目。
与其他方法相比,这种方法的优缺点是什么?
如果我理解正确,...
- 有组织和承包商。
- 组织可能与承包商 A、B、C 和 D 签订了合同。
- 该组织中的一个项目可能与其中一些承包商相关,比如项目 P1 与 A、B 和 C 相关,而项目 P2 与 A 和 D 相关。
- 每个项目都有项目负责人。项目 P1 可能有潜在客户 PL1 和 PL2。
- 每个项目负责人都可能与所有或仅与部分项目承包商相关。 PL1可能与A和B有关,PL2可能与A和C有关。
如果您希望您的 DBMS 保证所有这些实体的数据一致性,我建议您使用复合键。
table organization organization_no ... table contractor contractor_no ... table organization_contractor organization_no contractor_no ... PK (organization_no, contractor_no) FK organization (organization_no) FK contractor (contractor_no) table organization_project organization_no project_no ... PK (organization_no, project_no) FK organization (organization_no) table organization_project_contractor organization_no project_no contractor_no ... PK (organization_no, project_no, contractor_no) FK organization_project (organization_no, project_no) FK organization_contractor (organization_no, contractor_no) table organization_project_lead organization_no project_no lead_no ... PK (organization_no, project_no, lead_no) FK organization_project (organization_no, project_no) table organization_project_lead_contractor organization_no project_no lead_no contractor_no ... PK (organization_no, project_no, lead_no, contractor_no) FK organization_project_lead (organization_no, project_no, lead_no) FK organization_project_contractor (organization_no, project_no, contractor_no)