人员表设计思想 —— 也许会有点帮助

简介: 当我们出生的时候,我们有什么?性别、出生日期、姓名。除了这些还有什么呢?体重、属性、星座、血型、父母、哥哥、姐姐、籍贯、身份证号、其他。这些都是一出生就拥有的。 然后我们慢慢的成长,进入学校学习,进入社会打拼,打工、创业等等。

 

当我们出生的时候,我们有什么?性别、出生日期、姓名。除了这些还有什么呢?体重、属性、星座、血型、父母、哥哥、姐姐、籍贯、身份证号、其他。这些都是一出生就拥有的。

然后我们慢慢的成长,进入学校学习,进入社会打拼,打工、创业等等。我们又有了很多很多的信息。

 

画一个脑图,也许更清晰一些:

 

 

那么人员表要如何设计呢?看看上面说的,大家都共有的、基础的,而且常用的是什么?姓名、出生日期、性别。对就是这三个。于是我就建立一个人员基本信息表——Person_Info

Person_Info表里除了这三个字段外,增加主键PersonID、身份号和添加记录日期、最后修改日期。这个就是人员信息的核心表。

 

为什么要这么做呢?想想我们经历了风风雨雨,学校(学生信息)、公司(员工信息)、医院(体检、就医)、银行(申请银行卡、信用卡)等,不管是什么系统,这四个字段几乎是必填的,是标志我们的重要信息,其稳定性和通用性可见一斑。不把这个作为核心,把什么作为核心呢?

 

在做具体的项目的时候,我们可以根据需求设置其他的表,像脑图里的学历信息、工作信息等,都用PersonID来关联。目的就是要设定一种稳定的表结构。不管需求如何变化,这种表结构是不能变的。这个就是变化中的不变。看上面的脑图,加了很多的扩展信息,但是人员基础表还是核心,还是可以用PersonID作为关联字段。加了东西,这种结构没有变化。这是不是达到了稳定性喝可扩展性呢?

 

如果您的需求,没有出现在上面的脑图里,那么你可以试着加一下,看看是否打乱了这种结构。如果没打乱,说明这种结构是稳定的,如果打乱了,麻烦您说一下好吗?

 

在会员注册活动里,我设计了多个表,这个就是原因之一。其实就是按照这个思路来设计的数据库。

 

右上角的账户信息,增加了角色部分,这个是一时兴起。画脑图画的,想到哪里就画到哪里,画完了发现结构还可以,没乱。于是就保留下来了。账户的设计,是想实现一个人可以有多个登录账户,所以设置为一对多的形式,那么账户信息右面的表就都用账户信息的主键UserID作为关联字段了。

 

会员注册里的设计。我还是觉得脑图更容易理解一些,呵呵。

ER图
 


表关系图

 

 

 

相关文章
|
缓存 Java 关系型数据库
某人事系统架构搭建设计记录
某人事系统架构搭建设计记录
|
5月前
|
运维 程序员
程序员在企业中是如何做需求的
需求从哪里来,到哪里去
35 0
程序员在企业中是如何做需求的
|
6月前
|
编解码 缓存 数据库
【软件设计师备考 专题 】编写内部设计文档:屏幕设计和数据库设计
【软件设计师备考 专题 】编写内部设计文档:屏幕设计和数据库设计
110 0
|
6月前
|
缓存 算法 测试技术
【软件设计师备考 专题 】如何定义软件需求:系统化的目标、配置、功能、性能和约束
【软件设计师备考 专题 】如何定义软件需求:系统化的目标、配置、功能、性能和约束
314 0
|
缓存 Java 测试技术
痛击面试官!CURD系统也能做出技术含量
很多朋友可能会因为自己做的工作不是特别核心或者业务简单而引起面试中没有自信。但是很多公司面试的时候是可以接受面试者之前岗位的并发量、交易量低一些的。比如我们要招聘和我们交易量同等级或者以上的出来的人才,业界本来就没有多少,但我们还是要招人的。所以很多时候更偏向于考察面试者的设计底蕴、思考和解决问题的能力。
|
Unix Java Linux
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48648 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
|
Unix Java Linux
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1172 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』