今天完成的事情：

今天完成了方案评审

方案链接：http://my.wiki.ptteng.com/pages/viewpage.action?pageId=39682531

几个关键点的方案：

作为一个注册了新华美育的用户，我想要从新华美育平台的链接跳转到逗你学时，直接默认登录状态并可以使用所有功能，以便我不用再次注册就可以使用逗你学；
方案：对方使用我们提供的链接进行跳转，从这个链接上获取的信息有用户名（必有）、真实姓名、手机号（不一定有），以这三个数据进行静默注册并进行登录。关于静默注册部分，其用户名作为唯一标识，放入到user_openid_relation表中，其中type类型设为“xinhuameiyu”，用户名存在openid字段中；其真实姓名利用user表的现有字段name，存在其中；号码则直接存在user表的mobile中；静默注册时若发现已有手机号码，则将其合并到现有账号，以现在有账号资料为准，且每次从新华美育平台链接跳转都检查一次是否经过静默注册
登录部分：
方案1：从静默注册部分重定向至现有登录接口进行登录
优点：直接使用现有的登录逻辑，不会有遗漏
缺点：需要修改现有的登录逻辑，可能会出现未知的bug
方案2：在静默注册接口中写登录逻辑，静默注册接口完毕则为已登录状态
优点：不用实现重定向，且分离了登录逻辑，原登录逻辑不用修改
缺点：逗你学的登录逻辑有点复杂，可能会出现功能不全的bug

采取改动的方案1，对方提供信息并解析进行静默注册后，跳转至前端指定的页面，传递参数，然后跳转到相应的PC逗你学（从新华美育网站跳转）或H5页面（从微信公众号跳转）

作为运营者，我想要能够搜索想查找的指定用户，以便减少翻页寻找的工作量；
可以根据用户名、手机号来进行模糊查询，以及根据订单总金额和订单总数做上下限查询
方案1：使用常规动态查询一次查出

优点：一次查出
缺点：根据现有的表和要实现的功能，要进行跨数据库查询，以及在SQL语句中使用乘法、加法，SQL语句十分复杂，可能需要优化SQL语句
方案2：查出所有新华美育的用户，然后再根据查询条件筛选已经查出的用户
优点：实现难度低
缺点：需要多次查询数据库，若用户量过多，每次查出所有用户可能会出现性能瓶颈

采取方案1，直接写长而复杂的SQL

后面有需求增加，想要要求从新华美育用户可以设置手机号码和邮件，但是那个逻辑并不是我写的，并且我无法预估是否会延期，只能告诉PM如果要做的话是可以的，但是很有可能会延期，这件事情便取消了

然后尝试了跨数据库查询，因为在后台统计时要用到

之后尝试使用sum（）函数写SQL语句，还未完成

明天计划的事情：

编写SQL语句，完成假数据编写

遇到的问题：

需要根据订单总额度的上限和下限进行动态查询，但是订单的金额必须要从几个表中查出数据然后再相加才知道是否符合查询条件。想出两种方案：

1.是上面说的直接用SQL语句求和、比较

2.全部查出来，再使用条件筛选

采用了第一个，但是SQL语句有点难写，还是跨数据库的，不过明天早上就能写成

收获：

以上