规范写法:
1. 表名 小写 加 _
2. 字段 首字母小写第二个单词字母大写
userId
userName
userPassword
一. 设计原则:
遵循三个范式:
第一范式 属性的原子性约束 即表的列的具有原子性,不可再分解，即列的信息，不能分解, 只要数据库是关系型数据库,自动满足1nf
第二范式 记录的唯一性约束 在第一范式的基础上,目标是确保表中的每列都和主键相关
第三范式 字段的冗余性约束 目标是确保每列都和主键列直接相关,而不是间接相关(另外非主键列必须直接依赖于主键，不能存在传递依赖).
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原 则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键 相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个 表：Customer和Order。Order表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer表里包含该客户信息的那 一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和 维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接 和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在 数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考 虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓 等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。
二. 数据库设计字符规范
采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线'_'组成,共63个字符.不能出现其他字符(注 释除外).
注意事项:
1) 以上命名都不得超过30个字符的系统限制.变量名的长度限制为29(不包括标识字符@).
2) 数据 对象、变量的命名都采用英文字符,禁止使用中文命名.绝对不要在对象名的字符之间留空格.
3) 小心保留词,要保证你的字段名没有和保留词、数据 库系统或者常用访问方法冲突
5) 保持字段名和类型的一致性,在命名字段并为其指定数据类型的时候一定要保证一致性.假如数据类型在一个表里是整 数,那在另一个表里可就别变成字符型了.
三. 数据库命名规范
数据库,数据表一律使用前缀
正式数 据库名使用小写英文以及下划线组成,尽量说明是那个应用或者系统在使用的.比如:
web_19floor_net
web_car规范
备 份数据库名使用正式库名加上备份时间组成,如:
web_19floor_net_20070403
web_car_20070403
四. 表名命名规范
数据表名使用小写英文以及下划线组成,尽量说明是那个应用或者系统在使用的.
相关应用的数据表使用同一前缀,如 论坛的表使用cdb_前缀,博客的数据表使用supe_前缀,前缀名称一般不超过5字
比如:
web_user
web_group
supe_userspace
备 份数据表名使用正式表名加上备份时间组成,如:
web_user_20070403
web_group_20070403
supe_userspace_20070403
五. 字段命名规范
字段名称使用单词组合完成,首字母小写,后面单词的首字母大写,最好是带表名前缀.
如 web_user 表的字 段:
userId
userName
userPassword
表与表之间的相关联字段要用统一名称,
如 web_user 表 里面的 userId 和 web_group 表里面的 userId 相对应
六. 字段类型规范
规则:用尽量少的存储空间来存 数一个字段的数据.
比如能用int的就不用char或者varchar
能用tinyint的就不用int
能用 varchar(20)的就不用varchar(255)
时间戳字段尽量用int型，如created:表示从 '1970-01-01 08:00:00'开始的int秒数，采用英文单词的过去式；gmtCreated:表示datetime类型的时间，即形如 '1980-01-01 00:00:00'的时间串，Java中对应的类型为Timestamp
七. 索引使用规则
1) 逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引.考虑数 据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写.
2) 大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也 是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上.
3) 不要索引blob/text等字段,不要索引大型字段(有很多字 符),这样作会让索引占用太多的存储空间.
4) 不要索引常用的小型表
不要为小型数据表设置任何键,假如它们经常有插入和删除操作就更别 这样作了.对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间.
八. sql语句规范
所有sql关键词全部大 写,比如SELECT,UPDATE,FROM,ORDER,BY等,所有的表名和库名都要用``包含
如:
SELECT COUNT(*) FROM `cdb_members` WHERE `userName` = 'aeolus';
九. 其他设计规范
1) 避免使用触发器
触发器的功能通常可以用其他方式实现.在调试程序时触发器可能成为干扰.假如你确实需要采用触发 器,你最好集中对它文档化.
2) 使用常用英语(或者其他任何语言)而不要使用编码或者拼音首字母缩写
在创建下拉菜单、列表、报表时最好 按照英语名排序.假如需要编码或者拼音首字母缩写,可以在旁边附上用户知道的英语.
3) 保存常用信息
让一个表专门存放一般数据库信息非 常有用.在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息.这样可以实现一种简单机制跟踪数据库,当客 户抱怨他们的数据库没有达到希望的要求而与你联系时,这样做对非客户机/服务器环境特别有用.
4) 包含版本机制
在数据库中引入版本控制 机制来确定使用中的数据库的版本.时间一长,用户的需求总是会改变的.最终可能会要求修改数据库结构.把版本信息直接存放到数据库中更为方便.
5) 编 制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档.
采用给表、列、触发器等加注释的数据库工具.对开发、支持和跟踪修改非常有 用.
对数据库文档化,或者在数据库自身的内部或者单独建立文档.这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少。
6) 测 试、测试、反复测试
建立或者修订数据库之后,必须用用户新输入的数据测试数据字段.最重要的是,让用户进行测试并且同用户一道保证选择的数据类型 满足商业要求.测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序 原型检查数据库.换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据。
