You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
|
|
|
|
数据上行办法
|
|
|
|
|
|
|
|
|
|
|
|
1、为每个厂商提供Mysql库，限定登录访问的IP地址，
|
|
|
|
|
|
对表授权，分配select ,insert 权限，没有Update,Delete权限
|
|
|
|
|
|
|
|
|
|
|
|
2、业务系统每天定时上报数据（频率视业务属性而定，可以是24小时，也可以是2小时）
|
|
|
|
|
|
|
|
|
|
|
|
3、此处创建表的结构信息为与电教馆、业务系统、业务部门共同讨论确定后的数据结构信息，参照国家相关标准
|
|
|
|
|
|
|
|
|
|
|
|
4、上报表为流水日志表，每次业务系统上报的数据，不能删除和修改，完整记录上报信息。
|
|
|
|
|
|
|
|
|
|
|
|
5、上报表需要增加一列，为上报时间列，可以理解为时间戳，后面的增量以此为标记进行提取。
|
|
|
|
|
|
|
|
|
|
|
|
6、数据基座 定时（比如每2小时），将各上报数据表中的数据进行检查，检查内容：
|
|
|
|
|
|
a) 教育机构十位标准代码
|
|
|
|
|
|
b)教师编号 （以提供基础信息的系统，比如目前看是天喻公司提供的教师编号为准，它是guid,这里就是guid,下同）
|
|
|
|
|
|
c)班级编号
|
|
|
|
|
|
d)学生编号
|
|
|
|
|
|
采用类似于 select t1.*,t2.机构名称 from 业务表A as t1 left join 标准机构表 as t2 on t1.机构代码=t2.机构代码 where t1.上报时间>=2023-03-01 and t2.机构名称 is null
|
|
|
|
|
|
如果数据集不为空，说明存在不符合条件的上报数据,记录到上报异常日志表中，标识为待处理，同时，将符合检查条件的数据入库。
|
|
|
|
|
|
|
|
|
|
|
|
7、对应每一张上报日志表，有一张工作表，为最终真实结果。
|
|
|
|
|
|
|
|
|
|
|
|
8、业务系统通过读取错误日志表，修正后，重新上报数据，基座检查通过后，正确上报的数据，同步修改错误日志表中相应业务主键ID的数据信息为已处理。
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
|
|
数据下行办法
|
|
|
|
|
|
|
|
|
|
|
|
1、以只读表方式提供数据下行
|
|
|
|
|
|
2、基座为每个厂商根据数据订阅权限范围，维护每个数据库帐号对某张表的权限设定，是否有select 权限。
|
|
|
|
|
|
3、要求各厂商，定期将获取到的数据同步到本地数据库中使用。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
参考文档
|
|
|
|
|
|
https://blog.csdn.net/qq_43459116/article/details/124232387
|
|
|
|
|
|
|
|
|
|
|
|
优势：
|
|
|
|
|
|
1、长春政务云采用的数据上报方式中，主要办法是：可写数据库、同步API等方式，开放数据库方案也是主力方案。
|
|
|
|
|
|
2、无论是对业务提供方，还是基座方，逻辑简单，开发容易
|
|
|
|
|
|
|
|
|
|
|
|
缺陷：
|
|
|
|
|
|
1、不支持指定数据范围的授权，比如只想获取二道区的数据，目前无法实现。
|
|
|
|
|
|
解决办法：未来可采用细化授权区域的思路，在WEB上维护二道区，南关区等概念，指定创建create view的查询语句，然后将view提供给某个用户即可
|
