【无中生有】---2---数据库设计-1

任何一个系统目前都需要人的参与，电商系统需要客户，企业系统需要雇员，无人值守的系统也需要操作员。

所以在业务对象中，人是一个必要的设计对象，不管是不是核心业务对象

Person表

字段名	类型	作用
Id	整型	人数据id
Name	字符	用户姓名
Sex	整型	性别
Birthday	日期	出生日期
IDCard	字符	身份证号
Status	整型	数据状态
CreateTime	长高精度日期	数据创建时间
CreateBy	整型	创建人：人数据id
ModifyTime	长高精度日期	数据修改时间
ModifyBy	整型	修改人：人数据id
IsDelete*	布尔	数据是否逻辑删除

数据用户id之所以选择整型而不是guid类型，是为了索引优化。最后一个逻辑删除字段的使用，可以依据业务规则而改变，通常情况不建议直接物理删除人的数据，这样可能会造成业务数据找不到关联的人，但是，逻辑删除又存在一个问题，就是如果是一个人员变化较快的系统，可能会产生大量冗余数据，基于性能、运维、业务维护考虑，数据最好采用先逻辑删除然后物理转存废弃数据的方式。

另外，从数据安全性和业务安全考虑，创建时间和修改时间字段、创建人和修改人字段，都是必要，而且每个表都需要。但是更高安全性要求的数据则需要一个专门的操作记录维护表，而且人员的数据采用id而不是字符的姓名，是因为数据可变性的考虑。

这是一个人员的基础自然属性表，系统用户业务对象可以基于此表建立，但是不适合和此表完全融合。

User表

字段	数据类型	作用
UserName	字符	用户名
Picture	字符	头像地址
PersonId	整型	person表数据的id
Id	整型	数据id
Status	整型	数据状态
CreateTime	长高精度日期	数据创建时间
CreateBy	整型	创建人：人数据id
ModifyTime	长高精度日期	数据修改时间
ModifyBy	整型	修改人：人数据id
IsDelete	布尔	数据是否逻辑删除

UserName，通常此表也作用登录信息基础表，此字段也作为登录名，但是这样会有一些问题，尤其是登录方式多样化的时候，比如手机号、邮箱也可以登录，所以这个表就作为一个单纯的用户对象储存

而用户对象通常不会有惟一性，一个人会有多个用户名，因此personid字段不能做惟一性约束

LoginUser表

字段	数据类型	作用
LoginName	字符	登录名
Password	字符	登录密码
UserId	整型	User表数据的id
Id	整型	数据id
Status	整型	数据状态
CreateTime	长高精度日期	数据创建时间
CreateBy	整型	创建人：人数据id
ModifyTime	长高精度日期	数据修改时间
ModifyBy	整型	修改人：人数据id
IsDelete	布尔	数据是否逻辑删除

User表的数据和LoginUser表的数据是一对多的关系，尤其是目前登录方式多样化的情况下。所以以前流行的user表和loginuser表融合的设计不太适合了。

由于loginName不具备数据不变性，可能由于各种原因发生改变，所以数据变更需要确定一个原则，新增数据的登录名不能侵犯原有数据，否则，被侵犯数据的用户将发现自己登录名或者登录方式丢失的问题。

Contacts表

字段	数据类型	作用
Email	字符	人员的邮箱
Mobile	字符	手机号
Address	字符	人员联系地址
QQ	字符	qq号
CityName	字符	所在城市
ZipCode	字符	邮编
PersonId	整型	Person表数据的id
UserId	整型	User表的数据id
Id	整型	数据id
Status	整型	数据状态
CreateTime	长高精度日期	数据创建时间
CreateBy	整型	创建人：人数据id
ModifyTime	长高精度日期	数据修改时间
ModifyBy	整型	修改人：人数据id
IsDelete	布尔	数据是否逻辑删除

处于查询性能考虑，此处把用户表和人员表的id储存了

此系列以技术积累一般（没有超级牛人）的组织为目标，数据量根本就不打算向阿里和企鹅的方向去想，设计目标够用就行，没成为GCC流传度软件那样的妄想。

所以，如果不是那种会害人产生经济损失或者技术上确实太丢人的bug，希望大家拿砖轻砸。

版权声明：本文为博主原创文章，未经博主允许不得转载。