我之前发现了一个类似的问题（School attendance database）
我必须处理这些附加条件。
我认为基本表是以下条目。
如果这是表格，那么在理想情况下，数据库中的大约行数= 100,000 x 250（以yr为单位的工作日）= 25,000,000。现在，如果用户重复滑动或滑动行，则会加起来。比如1/3的员工这样做是为了确保出勤率得到标记。所以额外的行8,333,333总计约33,333,333。
其中一个问题是用户刷两次但只刷一次。然后我需要在第二次滑动中具有空值或在滑出字段中填充相同的值。这会添加所提到的额外行。 我认为另一个选项是每天运行后台任务来清理双用户条目。假设用户在8.00 A.M然后在8.10 A.M处滑动，因此系统会在当天结束时删除8.10 A.M条目。首先是在最后一个时间基础上。
然而，我怀疑我是谁。如果说用户在办公室工作过夜并且滑动可能是凌晨2点。滑动数据将是
我的问题是： 1.列出的行数是否可以被mysql，postgresql这样的数据库所接受，而不会延迟过多的回溯时间？我会更感兴趣的是开源数据库性能。 2.有没有更好的方法来格式化表格呢？
答案 0 :(得分：3)
简单的答案是你记录滑动而不是几天，然后对数据进行后处理以实现所需的跟踪 - 即使没有你的例子，还有更多基本的“外出吃午饭”或其他原因去在场外，每天需要多次到达和离开。
无论你做什么，你都会遇到多次滑动的问题 - 人们是“人”你会遇到边缘情况，即用户出于某种原因以奇怪的方式行事（通常是无辜的......） ）。
答案 1 :(得分：1)
这是一个小规范化：
用户表： 用户身份 名字 姓 电子邮件 WhateverOtherFields UserCreated [datetime] LastActivityDateTime [datetime]
AttendanceTable： AttendanceID 用户身份 事件ID SwipeIn [datetime] SwipeOut [datetime]
事件表： 事件ID 事件名称 EventLocation EventStart [datetime] EventEnd [datetime]
使用这样的布局，您可以在同一天保留多个出勤率。您可以允许用户使用SwipeIn开始出席，并在用户SwipeOut之前保持该出勤率。也许还给系统一个刷新过程，让你可以关闭那些从未接触过SwipeOut的参与者。通过添加类似事件表的内容来附加到考勤表，您可以跟踪事件等。你可以完全全力以赴或亲吻。
希望这有帮助！
答案 2 :(得分：0)
我没有看到任何问题。的行。许多应用程序通常具有这样的数据量。以下是我的意见：
1）您需要考虑正式的工作时间，比如上午9点至下午6点，即每天9小时。如果用户在午夜之后过期，则应将午夜之后的剩余时间添加到第二天的出勤时间。 滑动 - 1月1日 - 10日 - 上午8点+向外滑动 - 1月2日 - 2月 - 凌晨2点 1月1日至10月16日，1月2日至2月2日 刷卡 - 1月2日 - 10日 - 凌晨1点+向外扫描 - 1月2日 - 10日 - 下午10点 = 1月2日10点
所以你的总时间是1月10日的16小时和1月2日的11小时。
您可以在表格中添加的另一项内容是“已记录的小时数”列。不是很有用，但有时候有助于提取报告。您可以为此列添加值，仅用于清除不会被清除的条目，即最后输入。
答案 3 :(得分：0)
考虑以下步骤：
我认为有一种方法可以由系统自动管理这种情况。人的触摸必须有所帮助。