vba开发的系统属于cs架构

vbahomevbahome 论VBA 3周前 282 0

25、用excel vba做系统很多人都会有这样一个疑问:数据量大了不卡吗?其实这个问题不仅vba存在,其他任何语言都会面临这个问题,就跟一个小问题如果和14亿人有关那就是大问题,其实解决大数据量的问题不是在开发语言上找方案而应该在系统架构上来解决,数据量大的时候首要瓶颈是数据库,其次才是应用,当数据上规模后数据库的增删改查都会面临挑战,公号:左手Excel右手VBA)一套系统中80%的场景是查询,也就是说查询对资源的占用很高,最重要的是避免因为查询导致对数据的增删改产生影响,否则可能就会导致业务中断,那么对数据库做读写分离就是解决此问题的方案之一,即查询数据库专门应对查询操作,增删改用另一个库,同时库之间建立数据同步机制,这首先做到了业务隔离,避免业务不中断,进一步可以对读库做分库,将不同的查询分散到多个数据库去读取,降低对单库的压力,而读库的数量可以无限横向扩展,这也就是分布式的概念了,这样能在一定程度上解决大数据量在数据库端的瓶颈问题。

26、vba开发的系统属于cs架构,应用的源码都在客户端,这天然的会分散应用端的压力,当用户多,并发量大的时候自然每个客户端都是一个节点,这样就无形中形成了分布式架构,不用像bs架构的系统还得专门搞一系列的服务器进行分布式部署,系统卡的本质是对资源的争夺导致的,而资源不足唯一的办法就是增加资源,每一个看似配置不高的节点一旦形成分布式网络就能够抵御大数据量,公号:左手Excel右手VBA)大并发量的压力,每一个终端vba对业务的处理都是独立的,互相隔离的,所以一个用户即使卡了也不会影响别的用户,符合强内聚,松耦合的特征,不像数据库端的读写分离方案在一定程度上是牺牲数据一致性的,vba系统应用端的部署方式具有天然的,天生的,无需任何干预的分布式特质,所以很多人把excel vba做的系统卡归咎于vba语言本身是冤枉的,也是不公平的。

27、一提到vba做的东西,很多人首先想到的就是宏文件,Xlsm或者Xlam文件,给客户交付的时候也给一个文件显得特别low,搞得很多vba开发者,都不好意思说自己是开发人员,其实vba开发的程序也可以做成安装包,像大多数软件一样,双击下一步,下一步,跳过,完成,最终在桌面或者是程序菜单里就会有启动图标,双击图标就能自动加载Vba开发的文件,对使用者来说,几乎不用重新学习,驾轻就熟得很,因为大多数软件都遵循了这种习惯,但是很多vba开发者并不知道罢了。(原创公众号@左手Excel右手VBA)


版权声明

本文系作者原创作品,未经许可,不得转载。

喜欢0发布评论

评论列表

发表评论

  • 昵称(必填)
  • 邮箱
  • 网址
  • 验证码(必填)