写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范了
来源:互联网 发布:办公软件的培训 编辑:程序博客网 时间:2024/04/29 18:57
最理想的状态就是,大家的习惯是一致的,这样设计出来的东西别人好理解,好接手,更容易搞明白你的设计是什么意图,别人想在你的管理软件上做接口也更容易一些,集成多个软件系统也容易一些。
我们中国人的一个特色:谁提出个什么提议,大家都觉得不好,那你让他来吧,他更不行,就是你的这个不行,行的还没有,还没诞生,还在脑海里,这个坏习惯影响了严重我们的团队作战能力,反正我就不服,让我弄我也不会,就是你这个不行,哪里不行,我也说不出来,如何更行没有,那这个问题如何解决?多人协调配合方面,我们跟日本人、韩国人的差距很大,上大学时就被深深的影响过韩国人的团结。
有时候学会放弃是最大的进步,能提高效率,我比较支持秦始皇、成吉思汗、希特勒,都是统一方面的强硬派。
废话少说:
我经常用的字段有如下:需要注意的一点就是,你存的是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:什么时间修改的数据?
审核状态我一般分,若觉得哪里不妥或者命名有错的,我马上修改:
我们中国人的一个特色:谁提出个什么提议,大家都觉得不好,那你让他来吧,他更不行,就是你的这个不行,行的还没有,还没诞生,还在脑海里,这个坏习惯影响了严重我们的团队作战能力,反正我就不服,让我弄我也不会,就是你这个不行,哪里不行,我也说不出来,如何更行没有,那这个问题如何解决?多人协调配合方面,我们跟日本人、韩国人的差距很大,上大学时就被深深的影响过韩国人的团结。
有时候学会放弃是最大的进步,能提高效率,我比较支持秦始皇、成吉思汗、希特勒,都是统一方面的强硬派。
废话少说:
我经常用的字段有如下:需要注意的一点就是,你存的是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
1//------------------------------------------------------------
2// All Rights Reserved , Copyright (C) 2009 , Jirisoft , Ltd.
3//------------------------------------------------------------
4
5using System;
6
7namespace DotNet.Common.Utilities
8{
9 /**//// <summary>
10 /// AuditStatus
11 /// 审核状态。
12 ///
13 /// 修改纪录
14 ///
15 /// 2009.09.04 版本:1.0 JiRiGaLa 重新调整代码的规范化。
16 ///
17 /// 版本:1.0
18 ///
19 /// <author>
20 /// <name>JiRiGaLa</name>
21 /// <date>2009.09.04</date>
22 /// </author>
23 /// </summary>
24 public enum AuditStatus 审核状态#region public enum AuditStatus 审核状态
25 public enum AuditStatus
26 {
27 /**//// <summary>
28 /// 01 递交成功
29 /// </summary>
30 SubmitOK = 1,
31
32 /**//// <summary>
33 /// 02 开始审核
34 /// </summary>
35 StartAudit = 2,
36
37 /**//// <summary>
38 /// 03 待审核
39 /// </summary>
40 WaitForAudit = 3,
41
42 /**//// <summary>
43 /// 04 审核通过
44 /// </summary>
45 AuditPass = 4,
46
47 /**//// <summary>
48 /// 05 已驳回
49 /// </summary>
50 AuditReject = 5,
51
52 /**//// <summary>
53 /// 06 审核结束
54 /// </summary>
55 AuditComplete = 6,
56
57 /**//// <summary>
58 /// 07 撤销失败
59 /// </summary>
60 QuashFail = 7
61 }
62 #endregion
63}
1//------------------------------------------------------------
2// All Rights Reserved , Copyright (C) 2009 , Jirisoft , Ltd.
3//------------------------------------------------------------
4
5using System;
6
7namespace DotNet.Common.Utilities
8{
9 /**//// <summary>
10 /// AuditStatus
11 /// 审核状态。
12 ///
13 /// 修改纪录
14 ///
15 /// 2009.09.04 版本:1.0 JiRiGaLa 重新调整代码的规范化。
16 ///
17 /// 版本:1.0
18 ///
19 /// <author>
20 /// <name>JiRiGaLa</name>
21 /// <date>2009.09.04</date>
22 /// </author>
23 /// </summary>
24 public enum AuditStatus 审核状态#region public enum AuditStatus 审核状态
25 public enum AuditStatus
26 {
27 /**//// <summary>
28 /// 01 递交成功
29 /// </summary>
30 SubmitOK = 1,
31
32 /**//// <summary>
33 /// 02 开始审核
34 /// </summary>
35 StartAudit = 2,
36
37 /**//// <summary>
38 /// 03 待审核
39 /// </summary>
40 WaitForAudit = 3,
41
42 /**//// <summary>
43 /// 04 审核通过
44 /// </summary>
45 AuditPass = 4,
46
47 /**//// <summary>
48 /// 05 已驳回
49 /// </summary>
50 AuditReject = 5,
51
52 /**//// <summary>
53 /// 06 审核结束
54 /// </summary>
55 AuditComplete = 6,
56
57 /**//// <summary>
58 /// 07 撤销失败
59 /// </summary>
60 QuashFail = 7
61 }
62 #endregion
63}
很多人有一个坏习惯,软件用都不用就说不好用,所以我把用户什么时候第一次用的,最后一次什么时候用的,登录了几次我都记录下来,可以跟别人对账,一次都没用过,你怎么知道我的软件不好用?就用了几次,你就知道了?神仙啊?
我都说了,最好的程序是经得起折腾,你有水平就说我哪个字段应该修改为什么名字,如何修改,为什么不对,我的程序好处就是经得起折腾,经得起修改。
我最讨厌你参考RBAC吧,RBAC里有个鬼啊,啥也没有的空洞理念啊,你让我参考啥?你有水平就直接说,我应该哪个字段修改什么名字,为是什么?或者你干脆告诉我,找个资深老美设计师来改一下就不就可以了。
为什么我们会为公司的信息应用系统分散而零乱而发愁?就是因为我们连达成统一的用户表的这么第一步都很难,看下面的回复,这个表统一难道真的很不重要吗?那什么才重要?研发操作系统才重要吗?- 写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范了
- 写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范了
- 写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范
- 我的命名规范
- 我的命名规范
- 我的命名规范
- 我的c++命名规范
- Android--我的命名规范
- 编写程序过程中命名方法的参考——Java命名规范
- 我们团队的数据库命名规范文档
- 写给我的兄弟
- 数据库表、字段的命名规范
- 大家这么热情,我就献丑了 -- 我的iPhone软件
- 匈牙利命名法——命名规范(知道这些再看Windows程序就轻松多了)
- 转载百度百科-----匈牙利命名法(他可以帮我们更方便的理解VC,一起让我们的编程命名更规范吧!)
- 我推荐我们要有一套命名规范
- CSS命名规范(规则)-常用的CSS命名规则
- 帧动画的应用------自己在用的时候写了 估计一些刚入门的可能还不会用,就写出来留给大家使用
- C++ 变量作用域
- 拿“用户登录”的测试用例来说明黑盒测试方法
- 关于Ubuntu的ip设置
- 关于Ubuntu的ip设置
- Java抽象类和接口的区别
- 写给刚入门的兄弟们,我常用的几个字段命名参考,大家都这么命名,我们写程序就更规范了
- WORD2003打开关闭出错,提示normal.dot文件的问题
- 关于多线程和多进程
- 虚拟机起动报错 USB 不可用
- 研读《第八个管理》-怎样赶超印度、美国软件
- tinyXML
- 请你不要侮辱我的劳动成果侮辱我的程序代码,我不是传说中的菜鸟,请你不要对我进行人生攻击。
- 关于VMware虚拟机在笔记本上主板响声的解决
- 登录页面测试用例