签到新旧版本更替问题

之前也提到了签到，也给出过简要的解决方案。
这次是真的要把这个东西给做好了。

---

签到干了啥

业务上看
1.根据签到记录来判断今天是否能够签到，如果能够签到，今天又算是第几天签到
2.根据第2步给出不同的用户积分（5，10，15，20，20，20，，，）

代码层面看
1.得到签到状态
2.插入一天签到记录
3.插入一条积分修改记录

这次的改动：
app上有个签到入口，用的旧的代码以及旧的数据库
h5上有个签到入口，用的新的代码以及新的数据库

要求：要保证新的旧的2个入口看上去就是同一个。

---

之前的想法

之前不想麻烦别人，想要自己处理处理就完事，所以想法是这样的：

积分修改记录表在我手上，那么我在判断了之前是否签到状态后。如果我这里是未签到，那就再去查看一下积分记录表，看积分是否改动。
因为如果就算是在旧的接口上做了签到，在积分记录表里也还是会有记录的。
所以我这边有能力判断2个地方是否有一个地方签到了。

但是，，如果先到我这签到了呢。。。

那么顺着我的思路，就是让那边判断的时候，也调用一下我的这个查看积分记录的服务。
意思就是2个在判断的时候都多了一层判断：

我判断完我的再判断你的，
你判断完你的再判断我的。

这样的确是保证了一天不会签到2次。

但是数据同步的问题：

连续签到的次数不通，所给的积分不一样。
所以旧的表是一定要把数据放到新的表中来的。。今天也更dba商量了一下，准备时候把表给锁了，然后再迁移 。。

想一下这种情况：
表迁移了后，用户又在旧的入口签到，那么记录又插在旧的表中，那么这些后来的数据就无法更新到新的表中了。
难道还要一直迁移数据不成。

于是，，又顺着思路往下想：
那么不往旧的表里插数据了，涉及到写数据的时候，调用我的服务，往新的表中写。
嗯，很有道理。

---

。。。

最后发现，原来之前糊涂了，最简单的方法就是：

1.新的代码不用改（不再去判断积分记录啥的了，直接判断自己的签到记录即可）
2.数据库迁移
3.旧的代码由调用原先的数据库服务器改为调用新的数据库服务。

这样就一次性把所有的东西都放到了新的数据库中了。
ok
就这样