数据库表基本设计规则(一)

以下内容仅是个人工作至今的一些总结,不代表权威,后续会有一些针对具体业务需要设计的表结构后面会说,这里只是针对所有的表的一些比较通用的,我觉得比较不错的方案,仅供参考,欢迎大家交流学习,谢谢.

0.也是最重要的,所有表必须有备注,必须有备注,必须有备注.

1.要有唯一索引UNIQUE,普通索引看情况增加

　唯一索引是最后一道防线了,高并发的时候如果前端,代码,缓存都没有拦截住重复数据这里就会起到关键的作用

2.各个表中的同一个外键字段命名一定要一致(eg:商品编号(product_id),在商品属性表中,活动商品表中,供应商商品关联表中等等标中必须都叫product_id)方便维护

　如果不一致则在后期表多的时候,维护起来特别麻烦,浪费时间,而且还不爽

3.数据库引擎最好都是innodb

　有人说我不需要事务为可以不用innodb,是的,但是有些业务是一开始完全单表不需要事务,你设置了MyIASM,过了好久突然这些表需要用到事务了,你肯定不会记得当时这个表是MyIASM,然后就上线了,然后由于各种原因,数据不完整,也挺恶心的

   可以参考文章:http://www.2cto.com/database/201503/385669.html

4.命名一定要驼峰,经典的驼峰,没啥说的

5.触发器啊存储过程啊能不用就别用,数据库迁移或者换数据库的时候比较烦人

6.如果需要标识数据的状态的字段一个就可以了,我的话就命名state,0未审核-1删除1,2,3,4,5..... 只要有涉及需要标识数据状态的往上增加就可以了,不要觉得一开始是5个节点,待审核(1),主管审核(2),经理审核(3),财务审核(4),完成(5)

之后在3后面增加了一个节点,总经理审核,你就要把总经理审核变成(4),然后,财务审核(5),完成(6),这样老数据的状态就全都乱了,正确的排序就应该是往后增加

待审核(1),主管审核(2),经理审核(3),总经理审核(6),财务审核(4),完成(5),以此类推举一反三,还有不要弄一些什么是否删除字段,是否提交,是否....是否...之类的字段,一个状态都可以标识出来了

7.表越大越需要一些冗余字段,大表跨表查询太慢了,还有如果用一些mycat之类的分库分片软件也是需要冗余字段的,不要觉得冗余不好,都是看具体情况具体分析的.

8.所有表需要有自增id,名字就交id即可

9.涉及有状态的数据的表必须有一些流程记录的表与之对应,一个信息从开始到结束的过程都要记录下来.

10.不是特别重要,我的习惯,所有的表都要有以下几个字段

　 create_user 创建人,create_time varchar(20) 创建日期

　 update_user 更新人,update_time varchar(20)更新日期

　 remark 备注说明的意思

　 这几个字段都是varchar字段标红的是我想说的,一开始time相关的字段用的都是date或者timespan,后来开发中由于好多时候系统内,系统外对接,之类的原因导致时间转换的地方比较麻烦,最终还是改为varchar了,真是太方便了,2017-04-18 17:30:00这个标准的格式19个就够了,向上凑整20^_^

11.未完待续吧肯定还有只是目前想不起来了,本篇就命名"数据库表基本设计规则(一)"应该会有后续

欢迎交流学习,如需转载请注明出处,谢谢.

 ----------2014-04-21--修改了第二条的一些错别字增加了举例