我遇到了一个问题,我遇到了新的要求,并且不知道如何最好地构建我的数据库表。情况基本如下:
我将员工存储在Employees表中。由于产量增加,该公司不得不雇用许多临时雇员。所有这些员工,包括永久和临时员工,都必须将数据输入ERP系统。因此,基本上,员工将进入"订单" Orders表中有一个名为" EnteredBy"的字段。在理想的世界中,我会将这两种类型的员工都存储在Employees表中。
由于公司的不同系统和公司内部的团队没有相互交谈,一些临时员工确实成为永久员工,因此我们需要一种方式来报告所有订单#34 ;新"永久员工在他们是"临时员工时已经完成了#34;技术上和#34;合并"临时员工处理新永久员工记录的数据。
并非所有临时雇员都将成为永久雇员。所有订单都必须有一名"员工"附加到它,即持有雇员唯一标识符的外键。
我坚持如何融入临时员工的概念"进入这个数据模型,并仍然坚持订单的数据完整性。有什么建议吗?
当前数据库表结构:
更新1: 当我试图在数据库表设计中传达这个问题时,我决定寻求SO专家的建议。在我通过OOP分析解决方案时,[TempEmployee]的设计是一个[员工],但我无法将我的大脑包含在如何将其传达到表格设计和CRUD操作中。仅供参考,[员工]有许多字段,而[TempEmployee]有这些字段的子集,因此其所有字段都存在于员工中。
答案 0 :(得分:4)
(我假设可以将临时员工加载为员工)
继承是建模中相当常见的场景 - 在您的情况下,似乎可以扩展现有的Employee结构,因此您可以按如下方式对临时员工进行建模:
TemporaryEmployee
- EmployeeID (PK and FK to Employee)
- StartDate
- EndDate
- Other temp employee fields here
由于TemporaryEmployee
也是Employee
,它共享Employee
主键,并且可以通过TemporaryEmployee.EmployeeId
Employee.EmployeeId
外键来强制执行参照完整性}。
Orders
的完整性不受影响,因为现有的Employees-Orders
RI不变。
扩展而不是改变的另一个好处是您没有改变任何底层模型,因此应避免因更改ERP系统而导致的回归问题(尽管测试仍然是必不可少的)。
修改,澄清:
现有ERP系统表:
CREATE TABLE Employee
(
EmployeeID INT identity(1,1) NOT NULL PRIMARY KEY,
EmployeeTypeId ? -- e.g. might be able to repurpose to identity Temporary employees?
-- Other Employee Fields here ... not all of these will be relevant to TemporaryEmployee
);
CREATE TABLE Orders
(
OrderId INT identity(1,1) NOT NULL PRIMARY KEY,
EmployeeID INT NOT NULL FOREIGN KEY REFERENCES Employee(EmployeeID)
-- etc.
);
现在您使用另一个表扩展Employee,而根本不更改上述模式:
CREATE TABLE TempEmployee
(
EmployeeID INT NOT NULL PRIMARY KEY,
-- Other extended fields here as per above
CONSTRAINT FK_TempEmployee_Employee REFERENCES Employee(EmployeeID)
);
答案 1 :(得分:0)
您可以在status
表格中添加Employee
字段,表示该员工是全职还是兼职。创建另一个表格,如:
create table temp_change_date (
employeeID int PK (FK),
change_date date
);
当update trigger
从临时变为永久时,在Employee
表格中使用employee
填充此表格。
这样Orders
会自动映射,您可以看到使用更改日期时临时员工创建的所有订单。