业务架构初探之一:实现EXCEL数据导入的三种方式研讨

业务架构初探之一:实现EXCEL数据导入的三种方式研讨

在开发管理信息系统时(MIS),EXCEL数据导入,即XLS文件导入,常常是我们需要实现的功能。
在实现EXCEL数据导入的功能的过程中,我发现,很多开发人员会忽视以下的实际问题:

  1. 在手工录入数据时,已经完成的数据较验,业务数据关联,数据限制等等工作,在导入时需要重新再做一次,如果漏做,会引起不合理的数据导入系统。
  2. XLS文件较大的时候,字符串的处理效率会降低,有可能引起CPU高占用
  3. XLS文件可能会出特殊的字符,或空白行影响,容易引起程序报错;

我在BS结构的系统开发过程中,也同样实现XLS导入的这样的功能的经验。简单可以概括为3种方式:
(1)直接上传,即在页面提供一个文件上传按钮,让用户将XLS文件直接上传服务器,然后,启动服务器端程序,读取XLS里的数据,并且,连接数据库,写入数据。
(2)页面JS预处理后提交,即,提示用户,在自已的电脑上打开XLS文件,然后,复制粘贴的模式,将数据引入页面,引用JavaScript程序,预处理XLS的数据,成为格式化的文本,后作为批量数据提交到服务器端程序。
(3)专用桌面程序提交,即,开发桌面程序,例如C#程序,在用户电脑上打开XLS文件,用桌面程序读取XLS数据,预处理,将在这个程序中向服务器端发送数据。

我们发现,以上2,3种模式,可以很好的解决上面提到的3个实际问题,最为稳定,系统后期运行成本最低。主要原因是,都利用了页面提交,将XLS字符处理的运算压力分散到客户的电脑一端,而不是服务器一端,这样,服务器的压力就小了系统就稳定了,客户的体验也比较好。

而遗憾的是,很多系统都未经仔细评估,直接采用第1种方式,直接上传XLS文件,而这种方式,对以上的3个问题,都不能很好地解决,甚至,埋下种种危机。

就是昨天20190219,就有一个案例,某多客户使用的平台系统,有 “联系人” XLS导入的功能,采用了直接上传的模式,由于某一用户上传的XLS文件,有10000行有特别字符,但是,看起来是空白的行记录,后端程序一读入XLS文件,服务器CPU马上100%占用,平台的其它进程瞬间挂掉,平台所有的服务即停止,投诉在1分钟之内就电话打到客服部门了。

这个是典型的单 一功能影响全局功能,单一用户,影响全局用户的重大运维风险的事件,实际的损失(平台稳定性,可信度损失)是相当的大的,原因,竟然是“简单的EXCEL导入”,可惜,可叹…

基于以上分析,以及实际经验,建议读者,在遇到同类型的问题的时候,多加分析与评估,尽理不要采用“直接上传”这做方式来实现XLS导入数据的功能,以减少后期系统运维的风险。

显然,第2或第3种方式,实现起来,是比较曲折的,特别是,需要用到不同的语言,不同的开发工具,会让某些开发人员觉得 “麻烦”。然后,这个看似麻烦的方式,却是有顺利导入数万条数据的成功案例的。

在某机房管理系统中,要实施对“配线架”这一数据的导入,然而,每个配线架有24个,或48个端口信息,即,XLS表中的每一行都是一个配线架的信息,而且,每导入一条数据,就要同时产生24,或48条端口信息,我们用了第(3)种方式,专用桌面程序提交,很好地实现了1万多个配线架的数据,数十万的端口数据,导入工作,整个过程,系统没有挂。 请注意,有1万个配线架的机房,这个系统,不是小系统哦,嘻嘻 *_^

以上的研讨,希望对您有所帮助,感谢阅读!

如果您能读到这里就点赞一下吧。

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值