不知道 大家的 数据库设计的时候，通用字段是怎么设计的。。。 但是我待过了 几家公司了。。。 大型一点的项目， 一般都有 这个几个通用字段：
createTime 创建时间 date
creatorId 创建人编号 bigint
creator 创建人 varchar
updateTime 更新时间 date
updatorId 更新人编号 bigint
updator 更新人 varchar
del 是否删除 tinyint 0为正常，1为删除
这几个通用字段，一般是 架构师，或者技术老大提出来的， 一般人无权 抗议。。。 其实呢，现在到了 我来设计数据库的时候，有这个权利 重新设计 的时候，我 这个时候 就会结合 项目经验和实际情况出发来 讨论和优化一下：
1，为什么这么多通用字段？
我觉得是 为了 出了问题的时候，好排查问题，而且 其他领导或者 老大问的时候，也可以 拿出 数据出来，这个就是证据， 特别是 大问题的时候， 可以 把 锅丢给其他人，，，至少问题不是系统造成的，，，（而实际情况，，，很少，而且一般没用，人家只会说你的系统体验差，，云云）
2， 简化，优化的思考
一个字段一个字段来吧。。。
createTime 创建时间 date updateTime 更新时间 date
这两个字段肯定需要的， 特别是 按实际出现的时候，和后期数据统计的时候 用到，，，就是一时用不到，，随着 需求的不断变化，很可能就用到了。。出了什么，也是可以通过时间来进行 排查的，，， 这两个 字段无可争议。
接下来是 创建者，和更新者的了：
creatorId 创建人编号 bigint creator 创建人 varchar updatorId 更新人编号 bigint updator 更新人 varchar
其实 在项目开发时间情况来说， 这四个四段，，，99% 的几率是 用不到的，或者无用的，或者有时候就是为 空的，，，甚至一点意义和价值都没有的。。。
1， 如果 有些表真的需要，那么就可以在 那个表上面加上去， 把他们作为 通用的字段，是 没有什么意义的
2， 从数据的角度来看，，， 加了四个四段，，， 对于 查询来说肯定也有影响效率了，，，从开发角度来看，也很可能影响开发的 效率，，，
3， 我刚开始接触到 这样的通用字段的时候，觉得 考虑挺周期的，挺好的，，，可是 如果真的是 自己开发项目的时候，就感觉特别的想吐血了。。。而且 关键还用不上啊。
4， 因此我 强烈建议 把 4个通用字段干掉，，，除非表真的用到了。。。 而且可以把 这几个字段 提取出来放入一个 日志表里面，， 增加，更新的时候 使用 AOP 来进行 写入 日志统计即可。
5， 看项目了，，特别是一些中小项目，，，完全没必要，，，一些老大看别人这样设计，自己也要这样设计，，还自以为是很 完美的。 特别是 项目开发时间比较赶， 如果是外包项目更加没有必要了，就应该 开发重点，这样的小细节算了，，，
6， 为了开发效率，，，和 软件的 运行速度，，，这四个字段，，，不要了。。。
3，是否应该逻辑删除
del 是否删除 tinyint 0为正常，1为删除
逻辑删除， 这个自动 一开始 看起来觉得很有必要，，，其实 思思深入思考觉得没有必要的。
1， 第一 技术老大说要，，，因为他已经不需要怎么写 CRUD的，他只负责核心代码，，似乎觉得影响不大，，，其实从开发角度来看，，，特别影响开发效率，，特别是 写 查询 语句的时候，都得排查 del 的字段值，，，特别的麻烦，，而且容易出现 漏了将逻辑 删除的数据排查的情况， 反而增加的 风险和问题的发生。。。 如果某些特别重要的表，可以加，而不是 每个表都加，，，特别是恶心。。。还怎么愉快的写代码？
2， 设置逻辑删除， 只有是为了防止 关键的 数据不小心 被删除了。 而 特别是 中小项目来说，，这样的情况 ，要恢复的情况 ，，，，很少很少，， 而且 是有数据库备份的，，，就算真的 逻辑删除了，，，一般也很少 有说 需要恢复过来的情况，，这样的情况 我是没有遇到过的。。。
总结
数据库的 通用字段： 只是 创建时间， 和更新时间 有必要，，其他都可以没有必要 。
为了 统一规范 ，
如果是 表字段里面需要 状态 字段的话， 首先 命名 为 bizStatus 业务状态 。 如果还有 其他业务状态，，就 以 bizStatus 为 前缀 ， 比如 日志状态 bizStatusLog
这样 我们看表结构的时候，如果是 业务状态字段 一眼就知道了。