处女作—关于系统基础设计问题

背景

最近因为公司要新做HR系统,也因为比较赶时间,所以工资这一块打算到二期再做,一期,主要的工作是把HR的人员调动和人员信息以及一些基本的流程给完善好。之前公司是在外面买了一个HR系统,这个系统设计的比较大的缺点是:一个人,不能有多个岗位,也不能有多个角色,更没法指定哪个是某个部门的负责人,只能以他的岗位是“负责人”来区分他是这个部门的负责人,之前在做权限系统的时候,因为人员的问题,花了好长的时间进去。今天我们主要讲的还是人员基础信息的问题。

需求

首先,现已在运行的系统,所有数据均是以账户(以下称工号)和部门信息挂钩。新做的权限系统,所有的人员、部门、岗位、角色等基础信息都是以前的旧系统HR通过作业定时同步过来的。现在由于新区域入场的关系,人员的调动非常频繁,所以公司提出了这样的需求:当人员调动后,会涉及一个人负责多个部门,一个人所属多个部门,一个人会有多个岗位,一个人有多个角色。这还不是关键,关键的是:甲负责A负责,当乙来接手的时候,可以看到甲之前所有的经过他的各类数据(流程、任务、公文、经营数据、文档),只要是以前经过甲的,乙来后,就要看到所有之前他的数据。现在,N多数据我们都是以工号来进行关联的,如:丁发起了一个流程,到甲审批。这些类别的数据,都是以具体的工号来实现。现在的情况是乙来了,就要知道甲之前审批的流程。工作任务也是如此。所以很多的场景就没法实现。

问题

要实现这些,以前系统所做的东西,就得重新来,数据不能只是以工号进行关联,就得多出一个附带信息:岗位。

岗位:如果一个岗位有N个人,那又如何知道N在个在一个岗位上是如何表现的呢,新来的人是接手别人的工作,还是新分出一个岗位的分信息出来呢,如:一个部门有两个主管,现在如果有个主管升职了,新来一个主管是接替他的岗位的,那他能看到的数据信息,就是以前的主管看到的所有信息;但如果是部门原有两个主管,现在又来一个主管,那么问题就来了,这个人的数据应该是全新的数据了,还是也能看到别主管的信息呢。

岗位接替

接替这个岗位的工作,会看到之前所属这个岗位的所有信息,这里,可能会涉及一些责任问题,如:这个任务是上个人未完成的,来接手他的工作,但不帮他接替他遗留的考核问题。所以,既要知道有这个事,又能明确是谁的责任。所以,只用岗位来无法满足,还得用工号来区分具体人员。

岗位新增人员

对于新增加的人,要接收到这个岗位的任务,又要看到这个岗位所能看到的数据,他所产生的数据,就是这同岗位的人的新数据

对于这样的需要求,如何去设计好这个系统的基础信息,并且还要考虑到以前系统的问题。

以工作任务为例:

当任务发起人,发起一个任务时,执行人应该是以什么样的状态去接收这个任务,他发起的执行人是否是选择执行的岗位,而不是具体的执行人呢。

如果选择是岗位,那么执行人只要是这些岗位的人,都会收到一条任务。有个执行人岗位变动(或是离职)了,有一个新的人来接替,新人来了,我又如何让系统自动知道这要为这个人生成一条新的执行任务的数据呢?

他又如何能看到这条任务,如何知道新来的人是来接替谁,又以什么样的条件来给他展示这条任务的执行情况。他个人执行的进度。

一要保留原来执行人的执行信息,又要让新来的人,来继续接手这个任务做下去。

如果是岗位新增加人员,只需要给他一条新的数据就好了,这条新数据,又如何去触发它生成呢?

一个模块已是这样,又如何关联到别的系统,别的模块呢?

如何去设计这个基础模块,以及后台别的系统,别的模块的数据如何存储,希望能集思广益,得到指点。

后续问题

假如真的设计出来了,对于已上线的系统和各模块,又如何去更新呢?数据的接收方便是不是都会变动了呢。

时间: 2024-11-10 21:34:37

处女作—关于系统基础设计问题的相关文章

企业级服务器设计与实现经验之插件系统基础篇

最初之所以要采用插件的形式进行开发,主要是为了解决功能服务的“热插拔”问题,在决定采用“框架+插件”的方式进行设计后,我们就更进一步,打算将一个个可以分割开来的拥有完整功能的组件都做成插件的形式,并且使同类型的插件的接口兼容,这样在以后需要改变时就可以灵活的进行替换.比如,将通信部分做成通信插件.日志记录部分做成日志插件等等. 首先,我们要弄清楚,什么是插件?我给出了一个定义,可能有失偏颇. 插件又称为扩展,是一种特殊的组件,用于增强和扩展基本框架的行为能力.插件和框架的通信协议是一组接口,插件

系统构架设计应考虑的因素

系统构架设计应考虑的因素 摘要:本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素,列举了系统构架设计文档应考虑的一些问题. 关键字:系统构架.设计.考虑.因素 正文:约公元前25年,古罗马建筑师维特鲁威说:“理想的建筑师应该既是文学家又是数字家,他还应通晓历史,热衷于哲学研究,精通音乐,懂得医药知识,具有法学造诣,深谙天文学及天文计算.”(好难哪,软件构架设计师的要求呢?大家好好想想吧.) 本文目录一.与构架有关的几个基本概念: 二.构架设计应考虑的因素概揽:

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试

机房收费系统数据库设计

之前,学习编写机房收费系统的文档时,曾写过 机房收费系统数据库概念设计模型--ER图 这篇文章,现在到了机房收费系统个人版重构阶段,需要再次进行数据库的设计.可以说,之前的数据库的概念设计给我现在的设计奠定了一定的基础,但是仍然发现自己的设计中有许多不合理并且需要改进的地方. 在这次的数据库设计当中,学习了一些数据库的命名规范,重温了经典的三范式(属性原子化,避免局部依赖,避免传递依赖).但是发现,在需求面前,一些分属两张表的字段,为了方便,还是得放到一张表中,不得不破坏三范式. 现在将自己设计

VB.NET版机房收费系统—数据库设计

之前第一遍机房收费的时候,用的数据库是别人的,认知也只能建立在别人的基础上,等自考中<数据库系统原理>这本书学完了之后,再去看以前的数据库,发现数据库真的还需要进一步的优化,下面是我设计数据库的一些见解,希望大家多提些意见. 数据库设计 E-R模型: 在观念模型设计阶段,一个系统都是建立在ER模型上的,设计好ER模型,很重要. 我设计的ER图: 系统中的实体:很简单,就是将系统中的名词都抽象出来,再具体了就是转换为数据库的逻辑设计时才要考虑的. 系统中的联系:在图中可以看得很清楚,这里我要重点

模块管理常规功能自定义系统的设计与实现(24--二个模块之间的关联[2])

父子模块之间关联操作(2) 上一节介绍了子模块中对父模块的一些相关操作.这一节来看看父模块中对子模块可以进行什么样的操作. 一.进入子模块的时候,限定父模块值.选择一个"省"记录,查看省下面的所有市的记录. 在选择了"江苏省"记录之后,按toolbar上面的"市",会进入市模块的界面.(在前一节的基础上,我又给河北省和浙江省增加了市,在下面的界面中将会看不到) 二.加入子模块的记录和聚合字段.上节中介绍了可以将父模块中的字段加入到子模块的grid

基于ARM9的指纹识别系统的设计和实现

生物识别技术是利用人体固有的生理特性(如指纹.脸象.红膜等)和行为特征(如笔迹.声音.步态等)来进行个人身份的鉴定. 生物识别技术比传统的身份鉴定方法更具安全.保密和方便性.生物特征识别技术具有不易遗忘.防伪性能好.不易伪造或被盗.随身"携带"和随时随地可用等优点. 生物识别的工作原理是利用生物识别设备对生物特征进行取样,提取其唯一的特征并将其转化成数字代码,并进一步将这些代码组成特征模板,人们同识别设备交互进行身份认证时,识别设备获取其特征并与数据库中的特征模板进行比对,以确定是否匹

解析大型.NET ERP系统架构设计 Framework+ Application 设计模式

我对大型系统的理解,从数量上面来讲,源代码超过百万行以上,系统有超过300个以上的功能,从质量上来讲系统应该具备良好的可扩展性和可维护性,系统中的功能紧密关联.除去业务上的复杂性,如何设计这样的一个协作良好的系统,搭建开发人员基础平台,一直是我研究的方向. SouceCounter(版本3.3.91.79)对源代码的统计信息如下: 下面来详细解析一下这个系统的设计架构,纯.NET技术架构方案,C/S WinForms系统. 系统分为Framework和Application两个部分,前者是框架(

电商抢购秒杀系统的设计_1_应用场景分析

电商抢购秒杀系统的设计_1_应用场景分析 概述 所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点.另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统. 评估系统处理能力 理论基础:LNMP的并发考虑与资源分配 虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服