这话就说得没道理了，不过周至觉得也没必要和关大斌多讲什么大道理，关叔啊，你们都不知道给自己置办下了一笔多大的财富！

不过倒是提醒了周至另一件事儿：“关叔啊，和恒超市的pos系统，你现在熟悉了吗？”

“你等等啊”关大斌站起身来走进自己的房间，然后取出来厚厚的一沓资料：“这些不知道对伱有没有用，我从信息部找来的资料。”

周至将材料打开看了一下：“就连和恒的系统都还是单机模式？”

超市的结算系统是一个可简可繁的系统，但是是非常具备前瞻性的项目，从现在的状态来看，和恒的超商系统其实就是一个读码器和一个出纳箱，外加一个信息记录终端。

要到每天晚上前端系统关闭之后，才会将这些记录传送到后台服务器，在服务器上进行一系列的财务清算，重新盘库调整整个超商的库存并且进行交易量结算和财务清算。

相比夹川糖酒公司一月一盘存，这样的系统能够做到日结，就目前来讲已经先进得不要不要的了。

但是在周至眼里，这系统依旧落后得一逼，因为它无法做到实时清结。

整个系统，白天的时候前端繁忙，夜晚的时候后端繁忙，这其实是对计算资源的极大浪费。

同时由于夜间批量的时长影响，等到结算完毕后已经离超市开门的时间不远了，如果最后从财务报告分析发现了一些问题，比如缺货补货什么的，留给物流中心的反应时间已经极短了。

事实上这套系统很多东西都只能做到t1甚至t2，也就是说信息处理时间会滞后一到两天，比如补货，那就只能通过算法设定临界值，就是根据均值判断明天这商品可能会缺货，在尚有一日或两日库存的情况下便提醒管理人员需要补货了。

对于超市来说这已经足够了，但是如果能够做到更好的话

如果能够做到更好的话，那就利用上网络，让前端每一次扫码出货的信息直接送到后台，让前后台均衡运算，实时控制超市的库存量，如果将进货扫描也同时进行的话，整个超市的后台就能够实时进行进出货的清点记录。

每日超市关门的时候，系统盘存，出纳，财会，诸多工作已经实时完成，管理者可以根据当日销售情况及时调整营销策略，调货补货，又充足的时间迎候下一次开门。

如果愿意，甚至可以改变超市的经营方式，从八小时营业制变为二十四小时不间断营业。

有了这套系统之后，只需要再进一步，拿一套物流系统与之配合，便能够在不久的将来，将超市开到网上。

于是亚马逊，淘宝天猫，京东网上商城就诞生了

这便是pos超商结算系统的进化论。

这套系统的设计原理本身其实并不复杂，甚至初期投入都不算太大，只是现在的人还没有这么超前的运用场景预设，还是如今理工人的那句老话追赶阶段，先解决有没有，再谈好不好。

大家都在摸着石头过河，对于互联网信息技术产业的未来场景应用，一个基于局域网构架的超商结算系统，或者医院门诊系统，便已经是大家想象力的极限了。

这就是理工学院派的劣势，大家都是等国家分配科研项目等习惯了，研究的方向更多也是解决国内急需的技术问题，对于助力商业应用这一块，大家都是一脸懵，不知道如何措手。

周至当年的毕业设计课题就是医院软件设计，导师也没有多余的要求，甚至代码编写都不需要，只要你能够画出一个合格的医院的工作流程图来就能够毕业。

也就是说将一个医院的各部门的工作，比如挂号，分配诊室，就诊，开药，结账，药房出药这一套工作分成工作模块和工作流，并且绘制出能够支撑其工作的数据库，控制程序，传输程序，运算程序，统计程序，完成系统设计就算毕业。

为此周至还特意回老家在三反叔的人民医院里待了两个月，搞出了一套系统设计方案，最后完成了毕业论文答辩。但是方案最后有没有被导师孵化成产品，那就只有天晓得了。

万丈高楼从地起，现在手里拿着的这个系统设计框架，周至准备拿给麦主任看看，并且试试看能否按照自己的思路，坚决按照服务器模式来完成。

关于互联网工作模式，现在业界也存在激烈的讨论。

那就是客户端模式和服务器模式的选择问题。

所谓客户端模式，就是为了解决信息传输瓶颈的问题，每个终端机上都要一套系统，使之成为“客户端”，这样就可以将那些能够在终端机上解决的问题，尽量全部在客户端运算解决，只有的确需要传输交互的数据，才通过网络传送到中央服务器，进行最终的“大运算”。

比如现在和恒的这个系统，就是典型的客户端系统。

而服务器模式其实就是后来的互联网模式，每台终端机无需下载客户端软件，而是通过终端机直接访问系统网站，一切信息都直接传送到中心进行存储，本地所需数据也是实时从网站读取，前端没有运算功能，仅仅是一个输入输出端口。

这样的好处就是实现了数据的唯一性，权威性，通用性，不会