前言
本文为吐槽文，欢迎前排围观，一起来扒一扒ES那些奇葩的坑。
关于版本
目前网上流传的XX版主要有7.1.7、8.4、9.2.335、9.4.124、10.199。因为XX版的存在，ES取得了不小的知名度。作为企业正版用户，我先吐槽一下：版本更新快，代码质量不敢恭维。早年我曾一年升级好几次，几乎每次都跳到到某个不稳定版本，结果不仅劳命伤身(C/S架构，客户端自动升级失败)，还陷入了无限升级的坑爹境地。
不管是不是正版用户，只要能满足需要，就不要为了某些新特性去升级。要注意的是现在X宝贩卖的10.199版存在很多bug,例如不能调用存储过程，运行缓慢等，不建议使用，相较而言9.4.124更稳定。
关于ESWEB
这玩意早已被吐槽得体无完肤了吧，慢！丑！冷！
如果按网站打开4秒以上就会流失一半用户的说法，ESWEB已流失殆尽了吧？
如果说工作台的VB界面是老土，那这个WEB界面是肿么回事儿？为啥也这么土？设计好的模板为啥到WEB版就揉到一起去了？？
各大QQ群谈WEB就呵呵，入冷宫，不翻身，有木有！！！
关于权限
这里包括许多方面，首先ES客户端要电脑管理员账户才好用，有木有?
其次，ES本身的角色权限除了admin，其他基本用不到，特别是dept admin，这货就是猴子派来的逗比啊，官方说设置admin的部门限制可以防止这货变身，问题是这货自己改自己的所属部门后还是能变身啊!
再次，ES的超链接存在权限缺陷，如果设置了“不存在则新建，存在则修改”那么任何人都将获得修改权！如果设置了“修改”方式打开的超链接，则任何人都获得查看权限！
关于网盘
网盘是旗舰版的功能，对于客户端来说是一个特制的不用填账号密码的FTP工具，用来做系统附件的存储方案是不错，可以避免用数据库直接存储大文件。
网盘的坑主要有两点：一是网盘的备份还原存在问题，明明有几G附件，备份出来肿么就变成几百M了勒？还原还是直接整个文件夹复制粘贴过去靠谱一点。第二个就是用户网盘，很多筒子想拿来作为企业内部的公共盘，我建议还是算了，内网建域，配置一下共享文件权限或者买台NAS，比这个要强百倍，直接双击打开修改都行，有木有啊!
关于界面
VB土黄的界面就不说了，请个好点的美工又不会怀孕，也就咱们80后能接受吧，90后那些界面党会喜欢ES才怪，哎，说多了都是泪……
关于后台服务
老是要重启服务是肿么回事儿，以前是一个月要重启一次，现在是一周重启一次，不然自动邮件，自动任务就挂了，别跟我谈升级，戒了!
关于自动编号
这玩意非常耗费数据库资源，另外存在跳号问题，建议尽量不使用，或用提数公式(最大值)实现。
另外即使新建不保存也会产生废号，一般用几年后分析数据库也会发现跟ID有关的表(例如IdUsed等)都奇大无比。
关于EXCEL公式
不管是不是EXCEL高手，一定不要把ES当EXCEL用，很多ES设计者本身的EXCEL水平一流，平时设计个表格，用EXCEL公式就可以完成很多事情。但在ES中，滥用EXCEL会有许多意料之外的后果，不说ESWEB的支持有限，偶尔出现EXCEL公式丢失，导致修改时的更新问题就够喝一壶了，另外，数组公式不能大量在明细中使用，否则数据多时表单打开会奇慢无比。
有许多新手不知道模板上的公式必须在模板打开后才能触发，想当然的认为模板上EXCEL公式改了，后台数据会自动更新，阿门，真相是多么的残酷。
关于VBA
同EXCEL公式一样，很多ES设计者的VBA水平也不赖，甚至能用EXCEL开发小工具。但在ES中，滥用VBA也会带来许多麻烦，其中最忌讳的是使用工作表的selectionChange和Change事件，这点跟EXCEL数组公式类似，导致表单打开时奇慢无比。
EXCEL公式和VBA都是客户端脚本，就像WEB中的JS代码一样，使用时要适可而止。ES本身的表单打开过程是这样的：首先下载和加载EXCEL模板，然后下载数据，逐个单元格填充数据，最后显示给用户。如果我们使用了Change事件，逐个单元格填充数据时就会重复执行事件代码，如果明细数据量比较大，呵呵，恭喜入坑。
关于表间公式
没错，这个ES的“精髓技术”也存在许多需要注意的事项。
一般来说，一个模板的表间公式包括提数和回写不超过10个，如果滥用，一个是数据库设计的架构问题，另一个是模板架构的问题。
表间公式中最稳定的是提数公式，回写公式中的新建表单和删除表单比较稳定，而修改，补充明细，删除明细公式有大概率会跳票，所以不滥用表间公式也是为了系统的稳定着想，这里俺不禁又要吐槽了：官方经常说他们某个大客户，几十几百十个并发回写没出过问题。问题是“ES表间公式一定稳定”这个命题只要有一个反例就能证明是假命题，正版用户们，你们说对不对？！
关于工作流
这个ES经常炫的技术被扒开后也十分骇人听闻。
工作流的原理是表单按设定的路线传递，传递过程中的每个节点都保存一个副本(Wi表)，这样撤销时，数据就可以回滚到某个副本。通俗点说就是一传十，十传百，例如表单有填报和审核两步，审核有10个人并行参与，那这个报表在数据库中会存储11份！如果每个表单都这样跑工作流，不久的将来咱们的数据库文件可能飙到到100G，数据分析师过来一看，呵呵，您的系统只有500M有价值的数据!问题是每次备份要100G啊，坑爹啊！所以能不跑工作流就不跑，能用抢先式就不用会签式，能用会签式就不用并行式。
我曾经见官方炫过下面这样一个工作流需求图，阿门，请上帝救救这家单位的数据库吧。
2017/7/7新增：工作流新建不保存也会生成一条repcase记录，这个表过大直接影响工作台显示速度！
关于工作台
成也工作台，败也工作台!
最早相中ES就是因为觉得工作台右侧的主表+明细的展示方式正是我需要的。我最早设计的物料表是带有进出明细的，在工作台点击某个物料时，下方明细就显示物料的近期收发情况，后来我学习了解了数据库的设计规范后，取消了这种设计。
我们不难发现ES的系统表都是符合第三范式的，但如果用户想在工作台展示详细的数据就只能使用第二范式来设计数据库，这意味这我们想在工作台的入库单显示物料描述，就要在数据库里也保存物料描述，我想在入库单显示供应商名称就要在数据表里也保存供应商名称。很多人没有意识到这种设计的可怕。
假设我们有基础表：物料表和供应商表。
如果按第三范式，入库单的设计是这样(简化字段)：合计96个字节
如果想在工作台显示描述信息，就是第二范式，入库单的设计是这样：合计374个字节
范式等级的差异十分明显，如果描述文字很多的话，这种冗余和浪费将十分严重，是数据库设计的大忌！依赖工作台直接显示是硬伤，除非显示规则能像表间公式一样可以设定!
关于其他
元芳，你怎么看？
村长点评：目前勤哲已经逐步没落，推荐Nxcells等新型平台来开发ERP