儿保上传问题分析 (42).docx

1.保健编号规则12 + substring(管辖街道,3,2) + right(year(出生日期),2) + month(出生日期) + 3位数自增 (一共11位)2.错误分析 以下数据统计来源月份备份数据库 (10.96.36.157)2.1 错误保健编号应上传儿保档案 280767保健编号为空 55168保健编号位数不对 334保健编号错误 （与街道不对应） 3894保健编号错误 （与出生日期不对应） 170575——————————————————————————————— 错误档案合计 2299712.2.跳号保健编号后三位不是+1递增，有的时候跳了好几百由于以上的错误情况，导致很多社区+月份已经自增到，无法继续自增2.3.漏传估计漏传数据量不小，具体数据由于不能连市平台数据库，无法查询3.数据量统计 儿保上传一共有十张表，其中有张表与保健编号相关按照之前上传规则(传-01-01之后出生的儿童)统计数据量如下：催访 435048儿保档案 34793三联单 1222体格检查 1329283询问记录 941506预约提醒 1092080专案管理 129147周岁小结 116017——————————————— 合计： 4079096 现与妇幼所沟通，只传-01-01之后的儿童，估计数据量会少点 4. 面临问题4.1 对于历史数据保健编号错误；数据漏传4.2 对于新生成数据现很多社区、月份的保健编号，已经或者即将自增到，新的保健编号无法生成 5. 解决方案5.1 常规解决a.所有保健编号重新生成b.市平台对应张表，选取某张表数据全部删除c.通过常规上传途径每天分批上传该表数据 PS: 和东软协商，按此种方式，东软每天接受数据量有限， 预计上传周期一个月 5.2 数据库直连a.所有保健编号重新生成b.市平台对应张表的数据全部删除c.与市平台数据库直连，通过校验后，直接入市平台数据库 PS: 该方案需要与东软协商，东软原有的校验程序可能不适合此方案。

排除校验过程和其他因素，理想上传周期一天 5.3放弃历史数据a.放弃历史数据不处理b.对于新数据，如果该社区、月份保健编号三位已经自增满了，则生成到其他社区、月份PS: 该方案只需要改动保健编号生成规则;缺点：没解决历史数据问题；新的数据将有可能不遵守 管辖街道+出生日期 的规则 。