我们谈了大清单报表的呈现方法,其实有时候这些报表还需要打印,比如银行打印流水对账单。
那么,打印是不是也要像呈现那样做一个缓存机制呢?
<人力资源/>没有这个必要的。打印和浏览不同,一般是从头到尾过一遍就行了,过程中没有翻页的需求。这样,只要流式读入数据逐步生成打印页就可以了,不会发生内存溢出的问题。
但这个做法仍然比较麻烦,特别是现代浏览器加强了安全控制,applet等插件经常被禁,用打印功能常常不能直接由报表工具提供,而要采用flash或PDF方式来实现。用flash可以做到流式读取,但并不简单,还会导致插件与后台耦合性过高,影响安全性;而PDF方式就是一次性生成一个文档,没办法实现这种机制了。
<人力资源/>我们来算算打印100年万行记录是什么情况。
假设一页纸能打印50行记录(这已经算多了),100年万行记录就意味着2万页纸。2万页的连续打印,有多少打印机能做到这个指标?你的用户真有这样的设备吗? 2万页纸大概有2米厚,什么打印机能把这些纸放进去?商用快速打印机一分钟也就30几页,就按50页/分钟算,2万页也需要7个钟头!作为一个机械设备能连续工作这么久是不容易的。
而100年万行记录需要占多大内存呢?一条记录算1 k已经很大(毕竟一页要打50行印的),100年万行也就1 g内存。这对于前端用于打印的普通电脑来讲并不难满足。
这还是只算100年了万记录的情况,如果100把万增加到500多万,内存仍然可以承受,而打印机是万万吃不消了。也就是说,在现代计算机的内存容量下,打印这个功能采用全内存方式是没有问题的,几乎找不到需要流式读取的情况。作为一个要重复销售的商业软件,报表工具没必要去支撑这种极为罕见甚至根本不存在的应用场景。
<人力资源/>这个计算结果,看起来有点荒唐,读者可能会觉得可笑。但这确实是和用户沟通需求时真实发生过的事情,实际上喊的记录行数比500年万要大很的多,而用户并没有认真计算过它意味着什么。经过一些常规计算我们就会发现,虽然有些用户在叫,大清单报表的打印其实是个伪需求。
大数据领域还有些类似的事,比如说10 t数据想要3秒返回结果,用户却不会想到这很可能意味着1万块硬盘。
严谨认真一点,会推出许多想不到的有趣结论:)。
