1. 企业应用系统设计之签到

1.1 企业需求背景

在企业应用开发中,有时候为了促进企业用户的活跃度,我们经常需要为企业应用设计一套签到系统。

签到系统根据功能性大致可分为当天签到，按周连续签到不支持补签，按周连续签到支持补签,按天签到支持查看历史签到记录四种。

1.2 签到系统设计

1.2.1 当天签到

参考来源：百度随意搜的图片，如侵权可删。

当天签到这种设计比较简单，只需要设置一个签到日期字段即可。

当签到时候判断今天是否签到，只需要判断今天的年月日是否相当于签到日期的年月日即可。

如果相同则已签到，否则没有签到，更新签到日期。

核心SQL判断方法:

DATE_FORMAT(create_date,'%Y-%m-%d')  = DATE_FORMAT(NOW(),'%Y-%m-%d')

1.2.2 按周签到-支持连续签到不支持补签

参考来源：蛙跳App 签到

连续签到不支持补签，这种需要设计设置两个字段，一个签到日期字段，一个连续签到天数。

我们可以看到，连续签到这种设计需要支持第四天和第七天签到金币要比平时签到奖励的多。

为了实现这种，我们需要做多种判断。

首先，当进入这个界面的时候，需要检查签到日期字段是不是昨天。

如果签到日期不是昨天，需要将连续签到天数字段修改为0，然后返回列表。

如果签到日期是昨天，将数据直接返回。

当点击签到的时候也要需要检查签到日期字段是不是昨天，如果是昨天，那么连续签到天数+1。

同时，还需要判断今天签到后连续签到天数是不是等于4 或者7 这种特殊的签到日，因为这两天比平时签到要奖励的积分多。

除此之外，我们还需要返回客户端签到情况，根据连续签到天数判断, 如果已签到返回true, 如果没有签到返回false.

1.2.3 按周签到-支持连续签到，支持补签

参考来源：京东金融App 签到。

这种签到方式需要支持补签，因此设计上要稍有改动。

由于补签可能引起之前连续签到天数和签到状态的变化。

我们这次需要设计两个字段，一个用来存JSON格式的文本字段，另一个用来存储连续签到天数。

• 当然还有一种最笨最垃圾的方法，一共设置十四个字段，分别包含周一到周日的签到日期和是否签到状态。
  比如：周一签到日期，周一签到状态，。。。周日签到日期，周日签到状态。
  如果这样设计浪费数据库资源，博主绝不建议这种方式设计。。。
• 除此之外，可能还有博主会推荐另外一种设计思路：存储所有的签到记录，比如签到id,签到日期，签到用户Id
  这种设计思路虽然理论上也可行，不过博主并不推荐这种设计思路。
  原因：首先签到数据不管怎么变，按周签到，最多只需要维护七天的数据即可，完全不需要看7天前的签到记录。

JSON格式的文本字段 用来存储周一到周日的签到数据，这个JSON数据一般是一个有序的集合。

集合中每个对象中有三种设计思路

• 第一种：只包含自己的签到日期和是否签到状态。
• 第二种：包含标签名称字段，签到日期字段，是否签到字段。
• 第三种：包含签到图片URL地址,标签名称字段，签到日期字段，是否签到字段。

不管哪一种，我们始终只需要维护周一到周日七天的签到数据即可。

另外值得注意的是，补签不一定会改变连续签到天数，比如下面这个，我到周五，补签了周一签到的数据，但是由于签到日期不连续，所以并不需要修改连续签到天数，否则我们是需要修改连续签到天数的。

1.2.4 按天签到-支持查看签到历史记录和补签

参考来源：支付宝积分签到设计

这种方式显著的特征是去掉了连续签到功能，增加了查看历史签到功能，每天签到分数基本上一样。

如果是这种需求，上面的方法就不适用，

由于需要查看过去的历史签到记录，所以无法使用上面的方法复用字段，需要开启积分签到记录。

比如设计一张表：签到id,签到用户Id，签到日期，是否签到，是否补签

---

如果你对有更好的见解和看法，欢迎在评论区一起讨论～

交流即分享，分享才能进步～

本篇完～