昨天小主在群里问代码和数据库是不是一回事，肯定不是一回事。
既然问到数据库，那就简单介绍一下数据库是怎么存储数据的。
就拿每天打卡的表格来说,表格长这样：
签到打卡表格
数据库就是以这种相似的表格形式存储数据的。
那么上面的表格可以直接按这种形式存储吗？
答案是可以的，只不过按照这样的表格存储，不符合数据库设计规范，后期想要查询，统计数据会很不方便。
按照符合数据库设计规范的形式存储数据，上面的表格需要先进行拆分，拆分出两张表格。
第一张表格：人员信息表
人员信息表1
这里引出数据库设计第一原则，每列都需要遵循原子性。即，表中字段的数据，不可以再拆分。
原表中编号名字不符合原子性，需要拆分成两列，即编号，名称。
拆出的第二张表是打卡数据表，打卡数据表进行了变形，列转行操作。转换后表格长这样：
打卡数据表
打卡数据只列举了两天的打卡数据。这张表格包含三列，第一列编号，和第一张人员信息表的编号列对应。
第二列打卡日期，第三列打卡字数。
这里需要说明几点，数据库中存储的表，设计好之后，列就固定了，一般情况下，不会随便增加列。
按天生成的数据，每个人每天对应一行打卡数据。001号打卡5天，就创建5条打卡数据。
数据库一般不存储合计数，合计数是在查询数据的时候，按照要求自动计算出来的。
表结构设计到这里，基本上就完成了。
但是针对打卡群的特殊情况，不断的有人员出局，新人员入局，编号重复利用的问题，目前的表结构是不适合的，需要进行二次设计。
二次设计主要针对人员信息表进行。
为了实现编号重复利用，已出局人员打卡数据与新入局人员打卡数据分离的功能，需要增加几个字段。
人员信息表2
新的人员信息表增加了入局时间，出局时间，当前状态，显示编号四列。显示编号是为了解决编号重复利用的需求。
编号036的更替
比如036编号，刚开始Wemolly使用036编号，打卡数据表使用036编号记录其打卡记录。4月6日出局后，人员信息表Wemolly状态变更为出局。
4月7日，第三个账号入局，他的编号是066，显示编号是036，打卡数据表使用066记录其打卡数据，这样就与Wemolly的旧打卡数据区分开了，不会混淆，但是前台显示第三个账号是036号。
至此，数据库表结构设计完成，基本能够实现目前打卡群所需的所有功能。
这么设计打卡数据存储的好处就是可以方便的统计出想要的各种数据。
统计一段时间内，每各人写作的总字数，或者每天打卡字数趋势图，或者打卡时间段统计，大多数的人在哪个时间段打卡等等，非常容易就能统计出来。这是excel表格统计起来比较费事的事情。
前面讲的都是关系型数据库的设计原则。前几年开始流行的大数据，不在此次探讨范围内。
主流的关系型数据库有：
Oracle, 甲骨文公司出品的数据库软件系统
Mysql,甲骨文公司出品的数据库软件系统
sqlServer，微软公司出品的数据库软件系统
DB2， IBM公司出品的数据库软件系统
题外话：
在打卡数据表里的打卡时间列，是针对每一个个人的打卡时间。我的示例里面只有日期，没有时间。如果每个人打卡时间也记录的话，有了一定的数据积累，就会分析出每个人打卡时间的统计图。
比如第三个账号，基本上都是凌晨12点多就开始打卡。如果哪天他的打卡时间推延了，那基本上就是以下几个原因之一：
1.备用文用完了，此刻正在愁眉苦脸的写文呢。
2.太困，睡着了。
再多说一句，前面讲的是数据库数据存储，前端用户是感知不到的，前端用户还是使用原来的界面录入查询数据。
后端存储的样子和前端显示的样子不一样，这中间是怎么转换的呢？代码就是干这个转换工作的。
签到打卡表格
网友评论