MYSQL规范_MySQL

说明：此文档用于程序开发人员。目的是节约服务器资源，便于数据库管理，搭建一个规范化、高效率的数据库开发环境

 

• 数据库设计

 

MySQL常见的表类型介绍：

A : MyISAM数据表又分为MyISAM Satic (静态MyISAM)、MyISAM Dynamic (动态MyISAM)、MyISAM Compressed (压缩MyISAM)。

B :  InnoDB占用空间大，但是支持事务处理。

C：HELP表类型是放在内存中的速度很快。

设计：InnoDB

 

• 命名规范：

数据库,数据表一律使用前缀

正式数据库名使用小写英文以及下划线组成,尽量说明是那个应用或者系统在使用的.比如:

web_19floor_net

web_car

备份数据库名使用正式库名加上备份时间组成,如:

web_19floor_net_20070403

web_car_20070403

 

• 表设计

 

• 表和字段命名

数据表名使用小写英文以及下划线组成,尽量说明是那个应用或者系统在使用的.
相关应用的数据表使用同一前缀,如论坛的表使用cdb_前缀,博客的数据表使用supe_前缀,前缀名称一般不超过5字
比如:

web_user
web_group
supe_userspace

 

所有数据表名称，只要其名称是可数名词，则必须以复数方式命名，例如：oms_members(用户表)、oms_serverlist(主机表)；存储多项内容的字段，或代表数量的字段，也应当以复数方式命名，例如：params(parameters，自定义代码的参数个数)。

 

字段名称使用单词组合完成,首字母小写,后面单词的首字母大写,最好是带表名前缀.

如 web_user 表的字段:

userId，userName，userPassword

表与表之间的相关联字段要用统一名称,

如 web_user 表里面的 userId 和 web_group 表里面的 userId 相对应

当几个表间的字段有关连时，要注意表与表之间关联字段命名的统一，如omsgroup表中的id与groupcorr表中的id。(举例)

           代表id自增量的字段，通常用以下几种形式：

1. 最常用的核心id，或经常在URL中进行调用的，尽量用简写的形式，例如tid、pid、uid；

2. 有功能性作用，URL中偶尔用到的id，使用全称的形式，例如pluginid；

3. 没有功能性作用，只为管理和维护方便而设的id，可以使用全称的形式，也可只将其命名为id。

 

 

• 字段结构

• 允许NULL值的字段，数据库在进行比较操作时，会先判断其是否为NULL，非NULL时才进行值的比对。因此基于效率的考虑，所有字段均不能为空，即全部NOT NULL；

• 预计不会存储非负数的字段，例如各项id、数量等，必须设置为UNSIGNED类型。UNSIGNED类型比非UNSIGNED类型所能存储的正整数范围大一倍，因此能获得更大的数值存储空间；

• 存储开关、选项数据的字段，通常使用tinyint(1)非UNSIGNED类型，少数情况也可能使用enum()结果集的方式。tinyint作为开关字段时，通常1为打开；0为关闭；-1为特殊数据，例如N/A(不可用)；高于1的为特殊结果或开关二进制数组合；

 

1. 任何类型的数据表，字段空间应当本着足够用，不浪费的原则，数值类型的字段取值范围见下表：

 

• 索引使用原则

• 逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引.考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写.

• 大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上.

• 不要索引blob/text等字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间.

• 不要索引常用的小型表

 

• 外键命名规范

外键名称为FK_表名A_表名B_关联字段名

其中如果表名或关联字段名过长，可取简化5个字符

 

• 程序SQL语句

• 所有SQL语句中，除了表名、字段名称以外，全部语句和函数均需大写，应当杜绝小写方式或大小写混杂的写法。例如.

select * from members;是不符合规范的写法。

1. 很长的SQL语句应当有适当的断行，依据JOIN、FROM、ORDER BY等关键字进行界定。

2. 通常情况下，在对多表进行操作时，要根据不同表名称，对每个表指定一个1~2个字母的缩写，以利于语句简洁和可读性。如下的语句范例，是符合规范的

 

• 数据库设计文档规范

所有数据库设计要写成文档,文档以模块化形式表达.大致格式如下：

 

• 其他设计技巧
  1) 避免使用触发器
  触发器的功能通常可以用其他方式实现.在调试程序时触发器可能成为干扰.假如你确实需要采用触发器,你最好集中对它文档化.
  2) 使用常用英语(或者其他任何语言)而不要使用编码或者拼音首字母缩写
  在创建下拉菜单、列表、报表时最好按照英语名排序.假如需要编码或者拼音首字母缩写,可以在旁边附上用户知道的英语.
  3) 保存常用信息
  让一个表专门存放一般数据库信息非常有用.在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息.这样可以实现一种简单机制跟踪数据库,当客户抱怨他们的数据库没有达到希望的要求而与你联系时,这样做对非客户机/服务器环境特别有用.
  4) 包含版本机制
  在数据库中引入版本控制机制来确定使用中的数据库的版本.时间一长,用户的需求总是会改变的.最终可能会要求修改数据库结构.把版本信息直接存放到数据库中更为方便.
  5) 编制文档
  对所有的快捷方式、命名规范、限制和函数都要编制文档.
  采用给表、列、触发器等加注释的数据库工具.对开发、支持和跟踪修改非常有用.
  对数据库文档化,或者在数据库自身的内部或者单独建立文档.这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少.
  6) 测试、测试、反复测试
  建立或者修订数据库之后,必须用用户新输入的数据测试数据字段.最重要的是,让用户进行测试并且同用户一道保证选择的数据类型满足商业要求.测试需要在把新数据库投入实际服务之前完成.
  7) 检查设计
  在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库.换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据.