仓酷云

标题: MSSQL网页编程之公函转发流程自界说的数据建模 [打印本页]

作者: 爱飞 时间: 2015-1-16 22:34
标题: MSSQL网页编程之公函转发流程自界说的数据建模
php本地模拟的prepare底层就是mysql_real_escape_string，所以必须得用mysql_set_character_set去设置mysql->charset，否则就存在字符集问题。数据
　　开辟对照庞大的企业多用户办理信息体系(MIS)，不成能不触及到体系内多个用户之间的数据文件的流转、审批等功效的开辟。因为企业的需求老是跟着工夫推移不休产生变更，加上各个企业外部所设置的办公流程不尽不异，一套通用性对照好的办理信息体系应当能让体系办理员本人界说公函转发的流程。

　　只管笔者没无机会在已介入开辟了的MIS中完成出文件转发流程自界说的功效，可是，早在2002岁首就曾深切思索过这方面的计划。事先因为某些缘故原由不克不及公然本人的计划思绪，如今市情上已有很多MIS产物供应如许的功效，笔者又已去职，以是是时分把我的计划思绪收拾出来，和人人分享。

　　起首，让我们剖析需求，制订方针。

　　1)一样平常情形下，企业内的公函转发、审批是按部门或职位来转送，即对岗不合错误人。比方：某个流程的某个环节必要财政总监审批，往后财政总监换人，该流程应当不受影响。并且，流程中某个环节大概呈现某个部门中的任何一人都能审批，大概必要该部门的一切职员配合审批。
　　2)流程直达送，审批的公函一样平常分为文件和表单2种格局。文件格局的公函应当撑持批处置，即一次能够转发多个文件，审批时能够只退回个中某一个分歧格的文件，其他的文件能够转送到下一个环节持续处置。表单格局的公函应当能让用户本人界说表单格局，断定表单中的表项。同理，表单也应当撑持批处置。
　　3)流程中处置公函的举措应当能让用户本人界说。如许一旦往后增添了新的处置举措，也不必修正MIS体系的底层数据建模。固然，要完成新的处置举措，仍是必要在营业逻辑层编写响应的代码，不外和修正底层数据建模比起来，事情量要少很多。
　　4)每一个流程的环节数纷歧定不异，应当能让用户设定环节数，指定公函流转中每一个环节的发送部门和承受部门，处置形式，最长守候工夫。
　　5)当待处置的公函收回后，体系应当在守候工夫中按期向该流程中下个环节的用户(们)收回关照，提示该用户(们)实时处置，直大公文已被处置。假如超越最长守候工夫，公函还未被用户(们)处置，此次流程处置失利。企业办理层大概会请求纪录相干信息，以便在往后营业流程重组(BPR)时参考。
　　6)某些企业因为特别缘故原由，在某个流程中请求完成跨环节处置。比方，该流程有6步，实行到第二个环节时请求处置后能够跳过两头三个环节，间接转到最初一个环节期待处置。实在，这类情形下，其实不必定要在手艺层面上完成其天真性，这类惯例究竟是多数。用户只需界说一个新流程，把下面流程的第1，2，6步复制到场出去，2个流程之间用流程名来辨别便可。一个优异的体系架构计划师应当充实使用现有的工具，不要甚么都自行架设开辟。

　　下面的需求对天真性请求较高，笼统化水平较深，以是在体现层和营业逻辑层的开辟量较年夜，早期投资较多，不外开辟终了后估量不需对底层数据库修正，便可满意往后不休变更的公函流转需求。假如不必要这么高的天真性，能够按实践项目简化某些假定前提。上面依照下面的需求举行用例(usecase)剖析和数据建模。

　　1)因为流程环节的发送方和承受方是对岗不合错误人，我们应当先刻画出全部企业的机构设置，断定每一个部门的权力职责。个中年夜的部门内大概有多少子部门，每一个子部门内又有分歧职位，卖力处置响应的事件。以是，可先创建一个树形干系的数据表来保留企业布局，然后，接纳权限表和用户组相分离的体例来保留每一个部门每一个职位的本能机能。这块的计划思绪见我之前公布的“浅谈数据库计划技能(上)、(下)”，我鄙人面间接给出大抵的数据表布局：

部门表(Department_table)
称号　　　　范例　　　　束缚前提　　　申明
Dp_id　int　无反复　　种别标识，主键
Dp_name　　varchar(50)不同意为空范例称号，不同意反复
Dp_fatherint不同意为空该种别的父种别标识，假如是顶节点的话设定为某个独一值
Dp_layervarchar(6)限制3层,初始值为000000种别的先序遍历，次要为削减检索数据库的次数

功效表(Function_table)
称号　　　　范例　　　　束缚前提　　　申明
f_idint　无反复　　功效标识，主键
f_namevarchar(20)不同意为空功效称号，不同意反复
f_descvarchar(50)同意为空功效形貌

用户组表(User_group)
称号　　　　范例　　　　束缚前提　　　申明
group_idint无反复用户组标识，主键
group_namevarchar(20)不同意为空用户组称号
group_powervarchar(100)不同意为空用户组权限表，内容为功效表f_id的汇合

用户表(User_table)
称号　　　　范例　　　　束缚前提　　　申明
user_idint无反复用户标识，主键
user_namevarchar(20)无反复用户名
user_pwdvarchar(20)不同意为空用户暗码
user_typeint不同意为空所属用户组标识，和User_group.group_id联系关系

　　申明：个中，按部门的分歧职位设置分歧权限的用户组，如某个用户组为“市场部营业员”，该用户组的用户可在流程“报销请求”中发送报销请求。

　　2)只管流程中的公函分为文件和表单2种格局，可是每一个文件/表单都应当有其独一标识，称号等属性。以是，我们把公函笼统化，把这2种格局的公函的共有属性提掏出来创建一张公函表。

公函表(Document_table)
称号　　　　范例　　　　束缚前提　　　申明
doc_idint无反复公函标识，主键
doc_namevarchar(50)不同意为空公函称号
doc_typechar(1)不同意为空公函范例

　　doc_type字段用来分辨公函格局，今朝只要2种格局，可设“1”暗示文件格局，“2”暗示表单格局。估量将来新增公函格局不会太多，以是该字段只需一名字符。文件格局的公函通常为在文件内流动好格局，我们可用一个二进制的字段间接保留全部文件的内容。文件格局的公函必要建一个表来保留相干信息，其大抵数据表以下：

文件表(File_table)
称号　　　范例　　　　束缚前提　　　申明
file_idint无反复文件标识，主键
file_namevarchar(50)不同意为空文件称号
file_valuebinary不同意为空文件内容
……

　　表单格局的公函要让用户本人界说表单格局，断定表单中的表项。有两种办法来完成：
　　①每当用户创建一个新格局的表单时，就新创建一个表，把用户输出的表单表项看成该表的字段。这类体例的长处是表单查询速率较快便利，营业逻辑层的开辟量较小。弱点是不太天真，假如企业所利用的分歧格局的表单较多(>20种)，全部数据库的布局显得对照凌乱，并且年夜部分表单中都有不异的字段，如许也增添了数据冗余。这类体例的数据建模以下：

表单总表(Sheet_table)
称号　　　　范例　　　　束缚前提　　　申明
sheet_idint无反复表单标识，主键
sheet_namevarchar(50)不同意为空表单称号
table_namevarchar(20)不同意为空表票据表名，如Sub_table1/Sub_table2

表票据表1(Sub_table1)
称号　　　范例　　　束缚前提　　　申明
sub_idint无反复表票据表标识，主键
option1varchar不同意为空表单表项1
option2varchar不同意为空表单表项2
option3varchar不同意为空表单表项3
……

表票据表2(Sub_table2)
称号　　　范例　　　束缚前提　　　申明
sub_idint无反复表票据表标识，主键
option1varchar不同意为空表单表项1
option2varchar不同意为空表单表项2
option3varchar不同意为空表单表项3
……

……

　　②对表单再举行一个笼统，把表单当作由多少个表单表项所组分解的一个汇合。这类体例的长处是相称天真，用户创建新格局的表单时只用从已有表单表项中勾选出必要的表项便可，并且全部数据库布局明晰，没无数据冗余。弱点是开辟对照庞大，事情量和下面比拟凌驾很多，并且表单查询速率较慢。上面是这类体例的数据建模：

表单总表(Sheet_table)
称号　　　　范例　　　　束缚前提　　　申明
sheet_idint无反复表单标识，主键
sheet_namevarchar(50)不同意为空表单称号

表单表项表(Option_table)
称号　　范例　　　　束缚前提　　　申明
op_idint无反复表单表项标识，主键
op_namevarchar(50)不同意为空表单表项称号
op_lengthint不同意为空表单表项长度
op_unitvarchar(10)同意为空表单表项单元

表单信息表(Sheetinfo_table)
称号　　　范例　　　　束缚前提　　申明
info_idint　无反复　表单信息标识，主键
sheet_idint不同意为空所属表单标识，和Sheet_table.sheet_id联系关系
op_id　int不同意为空表单表项标识，和Option_table.op_id联系关系
info_valuevarchar()不同意为空表单信息值

　　3)我们能够把公函转发的流程笼统化，看做一个实体超类。建表以下：

流程表(Flow_table)
称号　　　　范例　　　　束缚前提　　　申明
flow_idint无反复流程标识，主键
flow_namevarchar(50)不同意为空流程称号
flow_stepnumint不同意为空流程步数
flow_descvarchar(200)同意为空流程形貌

　　流程中的每步都能够笼统化成从发送方至承受方的用例，其数据建模大抵以下：

处置举措表(Action_table)
称号　　范例　　　　束缚前提　　　申明
a_idint无反复举措标识，主键
a_namevarchar(20)不同意为空举措称号
a_callvarchar(50)不同意为空举措所挪用的模块
a_descvarchar(200)同意为空举措形貌

　　申明：假如接纳面向历程的开辟体例，如纯剧本言语，能够把每个处置举措写成一个函数，挪用a_call字段纪录的函数，便可完成响应处置举措。假如接纳面向工具的开辟体例，能够用COM组件来封装处置举措，则a_call用来纪录响应的COM组件的接口办法。假如是在.NETFramework情况下，能够接纳Web服务的体例。固然，发送方、承受方和公函标识是作为输出参数的。

流程环节表(Step_table)
称号　　　范例　　束缚前提　　　申明
step_idint无反复环节标识，主键
belongint不同意为空所属流程标识，和Flow_table.flow_id联系关系
setp_orderint不同意为空所属流程的步骤序次
senderint不同意为空发送方标识，和User_group.group_id联系关系
receiverint不同意为空承受方标识，和User_group.group_id联系关系
a_idint不同意为空处置举措标识，和Action_table.a_id联系关系
a_typeint不同意为空承受方所需的处置人数
max_waitint不同意为空最长守候工夫
wait_unitvarchar(5)不同意为空守候工夫的单元

　　申明：a_type用来断定承受方所需的处置人数，“0”暗示需同职位的一切人一同处置，“1”暗示只需该职位的恣意一位员工处置，“2”暗示需该职位的恣意两名员工一同处置，顺次递推……一同处置的体例和处置举措有关，比方是投票体例，多数从命多半，仍是或人有一票反对权等等。大概针对某些处置举措还得细化，举行相干的数据建模，这里我就不细分下往了。

　　4)上面剖析公函转发的流程环节纪录。此时相称于实例化一个流程环节的工具，发送方和承受方应详细接洽到办理信息体系的某个(些)用户，而不是某个用户组。每经由一环节，我们除要保留这方面的信息，还必需保留该环节所转发的公函，和处置情况等信息。并且，该环节所转发公函数目年夜于即是一，以是能够参考我之前公布的“浅谈数据库计划技能(下)”中的“简便的批量m:n计划”，建表大抵以下：

流程环节纪录表(Step_log)
称号　　　范例　　束缚前提　　　申明
log_idint无反复环节纪录标识，主键
step_idint不同意为空环节标识，和Step_table.step_id联系关系
sendervarchar(100)不同意为空发送用户标识，相干用户组的User_table.user_id的汇合
receivervarchar(100)不同意为空承受用户标识，相干用户组的User_table.user_id的汇合
doc_idint不同意为空转发公函标识，和Document_table.doc_id联系关系
batch_noint不同意为空批量转发公函编号，统一流程环节转发的batch_no不异
statechar(1)不同意为空处置形态
sub_datedatetime不同意为空提交工夫
res_datedatetime同意为空处置复兴工夫
commentvarchar(255)同意为空　　　处置复兴正文

　　申明：
　　①统一流程环节转发的batch_no和该批第一条进库的log_id不异。举例：假定以后最年夜log_id是64，接着某用户一次转发了3件公函，则批量拔出的3条流程环节纪录的batch_no都是65。以后别的一个用户经由过程某个流程环节转发了一件公函，再拔出流程环节纪录的batch_id是68。
　　②state字段用来形貌其流程环节所处的形态，是正待处置，已被处置经由过程，已被处置采纳，仍是超越最长守候工夫被体系主动发出等等。经由过程这个字段我们对承受用户收回处置关照，还能够能够很简单的查询出一切超越最长守候工夫被体系主动发出的流程，以便企业办理层在往后营业流程重组(BPR)时参考。
　　③假如某份公函在某个流程中的某个环节被处置采纳，能够看做该公函在此次流程中被采纳至肇端点，最后发送用户可依据处置复兴正文修正公函后从头发送。

　　总结：
　　企业公函流程自界说应当是把企业内已流动了的公函转发、审批流程电子化，完成高效的无纸化办公，关于非正式的行动会商、协商、会议等商务举动其实不合适。当企业积累了必定数目的电子化公函转发的纪录后，能够在贸易征询专家和手艺开辟职员的帮忙下对其举行数据发掘，剖析出个中的低效、无用环节，举行优化重组，终极进步全部企业的合作力。作为手艺开辟职员，我们应当依据企业实践运作情形、资金投进范围，选择以后时代最合适的手艺办理计划，切不成为了展现本人的手艺气力，而把开辟庞大化，企业开辟并非寻求手艺开始进，并且最合适。
如果某个数据列里包含许多重复的值，就算为它建立了索引也不会有很好的效果。比如说，如果某个数据列里包含的净是些诸如“0/1”或“Y/N”等值，就没有必要为它创建一个索引。

作者: 若天明 时间: 2015-1-19 17:20
始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。

作者: 再见西城 时间: 2015-1-28 09:01
无法深入到数据库系统层面去了解和探究

作者: 谁可相欹 时间: 2015-2-5 14:36
代替了原来VB式的错误判断。比Oracle高级不少。

作者: 若相依 时间: 2015-2-12 07:02
外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

作者: 爱飞 时间: 2015-3-2 23:53
你可以简单地认为适合的就是好，不适合就是不好。

作者: 小妖女 时间: 2015-3-11 07:38
还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。

作者: 金色的骷髅 时间: 2015-3-17 23:10
多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

作者: 乐观 时间: 2015-3-25 07:29
很多书籍啊，不过个人认为看书太慢，还不如自己学。多做实际的东西，就会遇到很多问题，网上搜下解决问题。不断重复这个过程，在配合sql的F1功能。

欢迎光临仓酷云 (http://ckuyun.com/)