建表规范

来自技术开发小组内部wiki
跳转至： 导航、 搜索 
建立此规范的目录主要是方便日后的表信息查阅与维护，形同统一的共识，减少沟通成本，规则都是基于开发经验总结得出，如果其他同学或DBA有补充的
可以在此规范上进行完善！

表名字命名

采用有意义的单词与下划线结合的方式，全部小写，不适用驼峰命名法，建议：fmb_new_activity；不合规：fmbNew_activity

字段名字命名

采用有意义的单词与下划线结合的方式，全部小写，不适用驼峰命名法，建议：grade_level，category_id；不合规：gradeLevel,gradelevel

表与字段名字长度

一般需要控制在30个字符以内，太长了可读性差书写不方便，建议：fmb_new_activity；不合规：fmb_shopuser_correlation_activity，fmb_dianping_recommend_category

字段必须要有注释

每个字段必须要有注释，针对一个字段的值有多个说明的，需要在注释中逐一说明
比如：`order_status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '订单状态。0.未付款 1.等待发货  2.已发货 3.退货中 4.已退货 5.交易成功;6.交易关闭',
比如：`status` enum('wait','pass','shield') NOT NULL DEFAULT 'wait' COMMENT '等待，通过，屏蔽',

字段值必须为非空但有对应默认值

避免在部分程序逻辑中执行sql语句出现错误（字段不为空但是没有该字段赋值），统一规定为字段必须为非空但是有对应的默认值，常见的几种情况：
  • 字符串型的， `title` varchar(150) NOT NULL DEFAULT COMMENT '活动标题',文本类型的同样参考
  • 整型的，`shop_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '匹配商户ID',
  • 枚举型的，`shop_type` enum('shop','dianping') NOT NULL DEFAULT 'shop' COMMENT '商家类型',
  • 浮点型的，`latitude` float(10,6) NOT NULL DEFAULT '0.000000' COMMENT '位置经度',
  • 日期型的，`start_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '活动开始时间',

表结构信息必修有表名注释

针对建表的时候，除字段必须要有注释外，针对于表名同样也需要有对应的注释信息，参考：
ENGINE=MyISAM AUTO_INCREMENT=9222 DEFAULT CHARSET=utf8 COMMENT='活动主体表'

表引擎的选择

通常情况下选择myisam表引擎，主要是利于维护与修改,出现问题了易于修复，支持事务的表需要选择innodb引擎，效率要求极高的可以选用memory表

字段列的排序与列的增加

字段列的排序一般按照重要信息靠前，数字类型靠前，时间类型靠前，状态相关（比如排序的，点击量的，是否删除等）靠前，文本类型靠后的原则，
不能将新增字段全部在现有的列之后追加，需要考虑下字段之间的相关顺序

字段通用约定

通用约定就是针对这一个字段，大家都约定俗成这么使用了，个人在处理其他表的时候就不要标新立异，以影响阅读和理解，比如
  • uid：代表用户的唯一数字ID
  • aid：代表活动信息的唯一ID
  • title：代表对应的标题
  • content:代表内容
  • ctime:代表创建的时间
  • shop_id:代表商家ID
  • order_sn:代表订单号
  • topic_id:帖子的ID
  • 其他的就不一一列举了，目的就一个在已经形成的规则上面就不要再自我独创

状态字段的命名

一般采用is_开头来进行命名，比如是是否删除is_delete,是否置顶is_top,是否可卖is_sell等

长文本字段类型存储

针对表中含有长文本的字段或该字段基本不参与排序很少修改，只是用来存储信息用，都是要求将这两种情况下字段统一放到单独的扩展表中来存储
这样主表的容量比较小查询效率高，相应的修改维护操作执行效率高，比如：
目前的活动的正文内容（fmb_activity_content）与活动相关的信息（fmb_new_activity）是分开存储的，不好的例子是目前的圈子是混在一起的（grp_topic）

外键字段的处理

如果表中的一个字段对应的另外一个表中的字段，那么该字段应该在两个表中应该保持字段名称和字段定义的一致，这样在mysql查询层面会得到更好的查询效率

同一功能的表名命名

基本采取表名中含有某一特定关键词的方式来命名，这样显而易见，也容易通过表名归纳对应的功能，比如活动频道的表基本就都带有activity关键词，比如：
<source lang="php">

+-----------------------------------+ | fmb_activity_age | | fmb_activity_apply | | fmb_activity_category | | fmb_activity_content | | fmb_activity_image | | fmb_activity_join_shop | | fmb_activity_log | | fmb_activity_question | | fmb_activity_share | | fmb_activity_sourceurl | | fmb_activity_tag | | fmb_activity_type | | fmb_new_activity | +-----------------------------------+ 

</source>

字段索引的建立

这是一个比较大的范畴同时与个人对业务理解的能力有很大关系，但是通过对开发经验的总结，基本有如下几条比较普遍的规则：
  • 如果该列是唯一的值，那么毋庸置疑的选用unique来进行索引的处理
  • 如果该列是另外一个表中的外键或有关联，那么在大多数情况下是需要建立索引的
  • 如果该列是用到排序的，那么是需要建立索引的
  • 如果该列是用到过滤条件的，那么根据过滤条件的使用情况（组合的情况和查询的频次），建立单列索引或组合索引（地球人都知道该规则貌似说的都是废话，但是在实际过程中往往会忽视）
  • 后续再慢慢补充，当然索引不是越多越好，这个需要根据业务查询与更新的情况来确定，需要经验和分析，这是一个长期的过程！

使用索引注意问题

  1. 查询语句的where条件后边使用 “!=”或“<>”时，索引不生效，和普通字段一样
  2. 查询语句的where条件后边使用字符串函数或其他函数，索引不生效，和普通字段一样
  3. 使用连接(join)查询时，只有在主键和外键的数据类型相同时索引才会生效
  4. 查询语句的where条件后边使用Like关键字应注意，like '%jx%' 和 like '%jx'方式索引均不生效， like 'jx%'方式索引生效
取自“http://wiki.fumubang.net/index.php?title=建表规范&oldid=765”