我们中国人的一个特色:谁提出个什么提议,大家都觉得不好,那你让他来吧,他更不行,就是你的这个不行,行的还没有,还没诞生,还在脑海里,这个坏习惯影响了严重我们的团队作战能力,反正我就不服,让我弄我也不会,就是你这个不行,哪里不行,我也说不出来,如何更行没有,那这个问题如何解决?多人协调配合方面,我们跟日本人、韩国人的差距很大,上大学时就被深深的影响过韩国人的团结。
有时候学会放弃是最大的进步,能提高效率,我比较支持秦始皇、成吉思汗、希特勒,都是统一方面的强硬派。
废话少说:
我经常用的字段有如下:需要注意的一点就是,你存的是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:什么时间修改的数据?
审核状态我一般分,若觉得哪里不妥或者命名有错的,我马上修改:


1

2

3

4

5

6

7

8



9


10

11

12

13

14

15

16

17

18

19

20

21

22

23

24


25

26



27


28

29

30

31

32


33

34

35

36

37


38

39

40

41

42


43

44

45

46

47


48

49

50

51

52


53

54

55

56

57


58

59

60

61

62

63

64

65

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


1

2

3

4

5

6

7

8



9


10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36



37


38

39

40

41

42


43

44

45

46

47


48

49

50

51

52


53

54

55

56

57


58

59

60

61

62


63

64

65

66

67


68

69

70

71

72


73

74

75

76

77


78

79

80

81

82


83

84

85

86

87


88

89

90

91

92


93

94

95

96

97


98

99

100

101

102


103

104

105

106

107


108

109

110

111

112


113

114

115

116

117


118

119

120

121

122


123

124

125

126

127


128

129

130

131

132


133

134

135

136

137


138

139

140

141

142


143

144

145

146

147


148

149

150

151

152


153

154

155

156

157


158

159

160

161

162


163

164

165

166

167


168

169

170

171

172


173

174

175

176

177


178

179

180

181

182


183

184

185

186

187


188

189

190

191

192


193

194

195

196

197


198

199

200

201

202


203

204

205

206

207


208

209

210

211

212


213

214

215

216

217


218

219

220

221

222


223

224

225

226

227


228

229

230

231

232


233

234

235

236

237


238

239

240

241

242

由于我们设计水平有限,表结构会经常修改来修改去,这样都定义了,修改表字段名,我的程序就在编译阶段知道都影响了哪里了,我就不太担心表结构变来变去了,当然是在适当的范围内,总比经不起折腾好点吧。
还有就是,程序不变,表结构有变化,需要集成到现有的系统表结构上,那可以考虑采用视图方式或表结构映射方式例如


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

很多人有一个坏习惯,软件用都不用就说不好用,所以我把用户什么时候第一次用的,最后一次什么时候用的,登录了几次我都记录下来,可以跟别人对账,一次都没用过,你怎么知道我的软件不好用?就用了几次,你就知道了?神仙啊?
我都说了,最好的程序是经得起折腾,你有水平就说我哪个字段应该修改为什么名字,如何修改,为什么不对,我的程序好处就是经得起折腾,经得起修改。
我最讨厌你参考RBAC吧,RBAC里有个鬼啊,啥也没有的空洞理念啊,你让我参考啥?你有水平就直接说,我应该哪个字段修改什么名字,为是什么?或者你干脆告诉我,找个资深老美设计师来改一下就不就可以了。
为什么我们会为公司的信息应用系统分散而零乱而发愁?就是因为我们连达成统一的用户表的这么第一步都很难,看下面的回复,这个表统一难道真的很不重要吗?那什么才重要?研发操作系统才重要吗?