面向人员需求和供应的DB建模

Question

TL;DR -我正在寻找我的数据库设计的指导。我担心我现有的设计效率低下，无法处理大量的员工。

这将是很长的时间，所以请容忍我。我正在创建一个JEE应用程序，用于人员需求、供应和使用类型的web应用程序。

到目前为止，我已经做了以下(简单的部分)核心DB模型，如员工，部门，地点等。

关于供求结构的要点：

1. 每个员工的分配可以在0.1到1.0之间进行。
   1. 每个新员工自动被分配到1.0的池项目中
   2. 需要跟踪员工的分配到一周分配的粒度。今后可能需要进行每日分配跟踪。
   3. 员工可以得到部分( 0.1到1.0之间)或完全(1.0)的需求分配。
   4. 需求被进一步分成几个星期，每周都需要跟踪每个员工的实际分配情况。分配给需求的员工可以全部或部分分配给该需求的部分或全部周。

我计划将需求数据库表示构建为3个表。

Demand Master (DM): --这将包含创建的每个新需求的条目。基本要求的雇员人数和整个期间的需求。

DemandLineItem (DLI)：是存储需求员工需求的需求数据的第2级。

DemandLineItemDetails(DLID)：是详细信息的第三级，它将员工每周分配的详细信息保存在一周的级别上。

我设想的这三个表的关系是这样的

DemandMaster(DM) <-- 1 to many --> DemandLineItem (DLI) <-- 1 to many --> DemandLineItemDetails (DLID)

下面是一个虚拟数据集：

Table DM:
DemandId <--> StartDate <--> EndDate
Demand1  <--> 10 Feb 2014 <--> 24 Feb 2014

Table DLI:
DemandId <--> DliId <--> EmployeeRoleRequirement
Demand1  <--> Dli1  <--> Foreman
Demand1  <--> Dli2  <--> LineManager
Demand1  <--> Dli3  <--> Manager

Table DLID:

DLIID <--> DLID_ID <--> allocationstart <--> allocationend
Dli1  <--> DLIID1  <--> 10 Feb 2014 <--> 17 feb 2014
Dli1  <--> DLIID2  <--> 18 feb 2014 <--> 24 feb 2014
Dli2  <--> DLIID3  <--> 18 feb 2014 <--> 24 feb 2014
Dli3  <--> DLIID4  <--> 10 Feb 2014 <--> 17 feb 2014

问题陈述：

1. 这是创建跟踪需求的一种效率低下的方法，因为所涉及的联接数量众多。
2. 随着需求的增加，DLI和DLID数据将增加，并且很难执行快速CRUD操作。
3. 如果我将类似的结构转换为供应结构，那么当前员工的数据周数将是巨大的，尤其是因为供应结构需要将至少2年的数据作为“未使用的”或“可用的”分配。
4. 从上述“未使用”或“可用”池中减去承诺满足需求的拨款，这一事实使其更加复杂。

是否有更好的方法来维护这样的数据(每个员工的周/日数据)？

也许是更好的DB模型还是不同的方法？

我正在使用mysql -工作台和mysql数据库进行设计.计划使用JPA (hibernate提供者)作为ORM。

Answer 1

我认为重要的是你要保持原样。但是，您还需要创建一个扁平的结构来查看信息。(这可能是你所认为的效率低下的地方)。

您可以通过两种方法来处理这个问题，您可以将一个延迟的“基于代理的”ETL转换成一个更扁平的模式。或者您可以使用物化观点 (或其在数据库平台上的等价物)为您预先执行搜索，而不需要代理。

在CQRS中，这种区别称为读模型与写模型