写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范

最理想的状态就是,大家的习惯是一致的,这样设计出来的东西别人好理解,好接手,更容易搞明白你的设计是什么意图,别人想在你的管理软件上做接口也更容易一些,集成多个软件系统也容易一些。

我们中国人的一个特色:谁提出个什么提议,大家都觉得不好,那你让他来吧,他更不行,就是你的这个不行,行的还没有,还没诞生,还在脑海里,这个坏习惯影响了严重我们的团队作战能力,反正我就不服,让我弄我也不会,就是你这个不行,哪里不行,我也说不出来,如何更行没有,那这个问题如何解决?多人协调配合方面,我们跟日本人、韩国人的差距很大,上大学时就被深深的影响过韩国人的团结。

有时候学会放弃是最大的进步,能提高效率,我比较支持秦始皇、成吉思汗、希特勒,都是统一方面的强硬派。

废话少说:
我经常用的字段有如下:需要注意的一点就是,你存的是ID,还是FullName?还是Code 应该区分开来比较好。
ID:主键,每个实体都有他唯一的标识码,就像我们的身份证号码,一般建议采用单主键,好做外键,设置数据库主外键关联约束。
Code:编号,可以不输入,但是不能重复,我又时候会用程序判断,由时候会建立唯一索引,这样也自动不能重复了。
UserName:登录名,用数子或者拼音,登录时方便输入,例如“jirigala”。
FullName:姓名,这是真实的姓名,例如“吉日嘎拉”。

CompanyID:这个数据当时是归属于哪个公司的,因为员工是有可能换工作,调公司的。
DepartmentID:这个数据当时是归属于哪个部门的。
WorkgroupID:这个数据当时是归属于哪个工作组的。
StaffID:这个数据当时是归属于哪个员工的。

Enabled:数据是否已生效,很可能输入的数据经过审核后才会生效的。
DeleteMark:数据是否被删除了,我不能把数据真删了,那就找不回来了。
AuditStatus:审核状态,审核流程放在另外表里,只是状态,写在这个表里了,按严格来说,状态也不应该放在这个表里,应该放在工作流表里。

Description:设计的字段再多,也永远满足不了客户不断在变化的需求,多弄一个备注字段,所有放不下的,没地方放的内容,全部可以赛在这个字段里了,否则你就是设置1000个字段,可能会出现第10001个需求。SortCode:

CreateUserID:这个数据是谁创建的?把主键记录起来,因为直接记录姓名,可能会有姓名重复的可能性,例如在内蒙古我的名字重复的概率就高很多。
CreateUserRealname:创建人的姓名,虽然有些冗余,但是在列表里显示数据很方便,现在硬盘也大,冗余一些也无所谓。
CreateDate:这个数据是什么时候被建立的,出了事情还能知道是什么时候搞出来的,公安是非常重视,什么时候人被咔嚓了,最好是能详细到几点,在什么地点发生的。
ModifyUserID:谁修改了数据?
ModifyUserRealname:谁?
ModifyDate:什么时间修改的数据?

审核状态我一般分,若觉得那里不妥或者命名有错的,我马上修改:

Code

我都会把表结构定义也成一个文件,可以参考代码,当然这个是表结构设计好后用代码生成器生成的,手写太累:
Code
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值