基础架构不能东施效颦——流程中心数据结构解析
基础架构不能东施效颦——流程中心数据结构解析2017版流程中心的设计初衷是用于替代原来的工作流，在数据结构上，基本沿袭了之前的数据表。看了一下以bpm为前缀的这些数据表，给我的感觉是未免过于匆忙了。
作为一款推陈出新的产品，似应在推出之初，就应该对数据库表进行审慎地论证和分析，免得在继承了原工作流的设计思想的同时，也继承了原有的缺陷。
一、标记字段数据类型不统一
早期的工作流，经不断的改进和不同人的经手，内中的标记字段可谓五花八门，单字节的有，多字节的有；数字型的有，字符型的也有。新的流程中心照抄不误。以bpm_run_prcs为例：OP_FLAG，就是标记一下主办和经办，取值就是0和1，却被定义为varchar(20)；标记步骤状态的PRCS_FLAG，取值是数字，也还是定义为char(1)；PARENT字段存储的是上一步流程的FLOW_PRCS，为什么这次就不能将其改为和FLOW_PRCS一样的int(11)，却还是沿用以前的varchar(200)？200个字节的90%的空间，就这样白费了。PARENT_PRCS_ID，也是如此。
TIME_OUT_ATTEND和TIME_OUT_TYPE，都定义为tinyint(2)，如果这次将其改成tinyint(1)，也就是举手之劳。
要说到定义得比较规范的，那应该是MOBILE_FLAG、IS_REMIND和TEMP_PRCS_FLAG三个字段，其位置处于表字段的后边，估计是后期追加的吧，分别定义为int(1)或tinyint(1)，算得是中规中矩。
俗话说磨刀不误砍柴工，事先对数据结构有周密筹划和认真部署，那会为将来的编程带来很大的便利，还能优化程序的运行效率，也减少了更多的Bug出错几率和调试排错时间。
二、固有缺陷依旧
如果新的流程中心不打算取消显示会签意见的宏标记，那么就必须为bpm_run_feedback表添加存储会签人的部门和角色的字段，非此不能保留历史原貌。这也是广大用户吐槽不已的已完流程的“固化”问题的症结所在。早晚都必须改，没有趁此良机及时改，是个遗憾，早改比晚改好。
三、把选项的选择权交还给用户
软件运行中的操作，诸多选项的默认值如何取舍，是由用户自定义还是由设计者硬性规定？如何使得人机交流更加友善，是拍脑袋决定还是走群众路线？又怎样取得安全性和易用性的完美平衡？我认为这始终贯穿在软件开发的至始至终。
被用户诟病多年，此次2017版新的流程中心，在流程设计时，还是没有把选项的选择权交还给用户。
以新建流程步骤为例，这是新建步骤的初始画面：
各个选项的默认值，都是在代码级设置的，用户改不了。极端情况下，可能每个选项都要由操作者重新选取一遍。更何况这个默认值设置得是否合理呢。就拿公共附件中的Office文档详细权限设置来说，一般都是有一两个步骤允许新建、删除公共附件，哪有各个步骤都开放附件的5个权限的道理？
一个流程多至十几个、几十个步骤，众多选项都要按用户本单位的规则一个个地去点鼠标，稍有不慎就出错。如果在权限上出错就很可能会带来很大的不良后果。这其中的苦衷我想每个OA管理员都感同身受，纷纷吐槽是“闭门造车”，深层次地，还是没有真正树立市场意识，还是以我为中心的官商意识在作怪。
其实很多地方，解决起来也很简单。就拿流程设计来说，把选项交给MySQL数据库去管理，在数据库表里设置好各选项的默认值。新建记录时按字段默认值取值而不是由程序员在代码级主观臆定。既减轻了程序员的负担，还方便了用户随心修改，整个矛盾迎刃而解，又何乐而不为呢？
说明通达已经认识到架构需要改进，不过看起来是交给了不靠谱的人。 感觉还是停留在学生时代，玩玩那张开发状态。 新架构的流程中心比老架构要强多了， 数据优化尚待时日，毕竟才刚推出没多久 ispro 发表于 2017-5-22 10:18
新架构的流程中心比老架构要强多了， 数据优化尚待时日，毕竟才刚推出没多久 ...
做得再细致一些，避免把原来的缺陷带进来，把基础打牢，就免得将来的修改伤筋动骨，还给用户带来不便。其实这就是软件开发工作的规范化管理的问题。 本帖最后由 citc_darklg 于 2017-5-22 13:41 编辑
huaian 发表于 2017-5-21 16:43
说明通达已经认识到架构需要改进，不过看起来是交给了不靠谱的人。
感觉最近版本动荡太大。。。，稳定性不如人意 您好，非常感谢您的建议，我们接下来会把整体结构优化一遍，另外默认值的问题需要具体考虑到用户操作人性化来修改。 ispro 发表于 2017-5-22 10:18
新架构的流程中心比老架构要强多了， 数据优化尚待时日，毕竟才刚推出没多久 ...
数据库架构是地基，留下缺陷，高楼盖起来了，再想修补就难了。 佩服老兄的严谨认真，装上试用版，看了下表结构，没有细看，感觉没有质的提高。性能、可维护性，扩展性，是要精细考虑、平衡的。建议通达安排人多研究设计原则，并落地，既然是重构，就要跳出来，保留原系统优秀的业务逻辑！，重构架构，提高设计和代码质量！
按CGFT老兄的分析，又埋了一堆炸弹，跟当初通达一样，当前架构/功能实现了，但很可能丢掉未来的可持续发展。 本帖最后由 cgft 于 2017-5-22 16:36 编辑
liao99 发表于 2017-5-22 16:17
佩服老兄的严谨认真，装上试用版，看了下表结构，没有细看，感觉没有质的提高。性能、可维护性，扩展性，是 ...
老兄的“既然是重构，就要跳出来，保留原系统优秀的业务逻辑！重构架构，提高设计和代码质量！”说到了点子上。
“数据库架构是地基，留下缺陷，高楼盖起来了，再想修补就难了。”地基不牢，地动山摇啊。希望流程中心，建成伊始就是一个健壮的架构。
页:
[1]
2