问数据库设计-员工定时进出系统

EN

你在这儿开了一大罐虫子，伙计。在一家只做时钟系统的公司工作之后，我再也不想做了！

我意识到我的回答是非常概念性的，并且涉及问题的正常范围之外的几个问题，但这是为了概述这种类型的应用程序中的数据库设计和结构概念。这一信息来自最近我在这方面所做的专业发展，因此它不仅是假设的，而且在实践中得到了证实。

当您查看这种类型的系统时，最好最初使用指示符作为标志，这通常是与每条记录进行比较的次数。比较1000名员工的每一项记录并不是最好的办法！

例如，如果用户在24小时内进行了8次抽打(一天开始、早上休息、上午休息、午餐开始、午餐结束、下午休息开始、下午休息结束和结束一天)，则可以确定这段时间内不太可能有漏打和超时，但是如果24小时(开始、上午休息、上午休息、午餐开始、午餐结束、午休开始和一天结束)有7次打拳，您就知道没有打拳，而且该人忘记了一天的时间。注意下午的休息是怎么结束的。

然而，这不是充分证明，只是提供了一个指示性的参考，你将需要比较一个换班时间表和穿孔，以确保什么都没有真正错过。因为可能午餐结束和下午休息都错过了，留下了6次重击，所以您可以设置您的代码来标记任何对该员工来说不是X数的击数。在标记时，然后对该员工进行实际比较，找出实际发生了什么和错过了什么。

这并不意味着你没有比较所有的记录，但是问题是，取决于员工的数量，它可能会导致对每条记录进行精确比较的一些大问题，这通常是更好的方法，让更多的员工使用2台服务器，1台用于数据收集和接口，第二种用于运行比较过程。

正如我所提到的，对于这种类型的应用程序，为了处理不同的时间表，您还需要查看要与之进行比较的轮班计划。您将希望为每个员工保留一个空白记录，该记录将在开始轮班之前和结束轮班后给出相同的时间。这将意味着延长超过一段时间的加班的可能性很小。基本公式非常简单:班次中的小时数- 24小时/2=时间填充

现在，您可以将时间填充放在该用户的轮班计划之前和之后。但你仍然需要处理一个轮班互换，改变或超过24小时的轮班。这才是真正棘手的地方。你会想要看一张表的重叠时间(填充，移位和穿孔)，然后可以调和与任何未来的调整时间表，因为事实变化并不罕见的出席。

现在，您还需要持有病假和假期的缺勤时间表，然后需要在冲入/冲孔表中对此数据进行一般标记，因为这是与之相比的数据。当标记设置为一个时间段时，可以比较地跳过记录，并在报告中留下注释，而不需要运行其他操作来检查它。

在接近尾声的时候，注意到您需要如何忘记常规的日期/时间约定来度量一个变量的范围？更别提在多个日子里高效有效地工作了？因此，通常最好只使用dd/mm/YYYY :mm:ss的开始和结束时间，因为度量使用UNIX时间来计算已经过去的时间。为了便于审计，大多数系统确实需要一个“日期标记”记录，因此在发布报告时，服务器端可能需要对此进行处理。

最后，我还建议保存一个结果表，这将给出每个用户的报告结果，这样当您想要提供历史记录时，您可以动态地生成文档，但是您不必在每次请求报告时都浪费对记录的处理能力。

我希望这能帮到你!

从领域的角度来看，这不是完全正确的。

检查或排除故障需要时钟输入或输出/穿孔。所以，你需要为所有员工存储个人打拳记录。

在您的情况下，时钟表可能是派生数据。

时钟表应该是

+----------------+----------+------+-----+---------+----------------+
| Field          | Type     | Null | Key | Default | Extra          |
+----------------+----------+------+-----+---------+----------------+
| id             | int(11)  | NO   | PRI | NULL    | auto_increment |
| staff_id       | int(11)  | NO   |     | NULL    |                |
| clock_type     | int(1)   | NO   |     | 0       | 0-in, 1-out    |
| clock          | datetime | NO   |     | NULL    |                |
+----------------+----------+------+-----+---------+----------------+

我不认为你的设计有什么问题，就像我看到了糟糕的需求问题一样。你需要一个更好的定义，什么时候经理被改变，以说明在多天的轮班。也许最好的规则是，如果某人24小时没有下班，或者他们试图第二次计时，主管就会得到通知。您还可能需要数据库上的触发器，如果有丢失的时钟，则不允许时钟进入。或者，您可以允许时钟进入，并将丢失的时钟发送给主管采取行动。

您特别需要的一件事是审计(一个单独的表)，以便您可以看到谁在什么时候更改了记录。YOu不知道是谁改变了记录，如果有人对某人的时间提出疑问，那么旧的价值是什么。

时间计时(我假设他们会得到基于计时时间的报酬)是一项需要严格的内部控制的活动(在数据库级别，而不是在应用程序中！)如果要防止欺诈，内部控制绝不能停留在应用程序级别。)任何人都不应直接进入谈判桌。它们只应该能够通过指定它们所能做的事情的存储过程进行更改。

你可能想要对主管、副非主管有具体的规定。一般情况下，任何与时间有关的事情，都只能由人的主管在事后才能改变。我会有一个执行此操作的触发器，只有当时钟为null时，才允许输入时间表的人更改数据中的时钟。所有其他更改都应由该人的主管进行。因此，您可能需要一个表来存储组织结构，或者至少需要一个字段来显示员工的监督者是谁。

如果人们要根据时钟和数据来判断，那么你可能需要与你的会计人员和他们的审计师一起重新确定业务规则。这类事情的内部控制是非常复杂和棘手的，以得到正确的。

我看到的一个设计问题是时薪列，随着时间的推移，这会发生变化，您会想要知道这一点(尤其是如果由于某种原因在发薪期的中间发生了变化)，所以我会将其分解到一个相关的表中。同样，这个表的权利需要严格执行。除人力资源人员外，任何人都不应能够将数据输入每小时薪酬字段。