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提供给某个用户即可
|