数据库命名规范..docVIP

数据库设计 MySql数据库对象命名规范 Database Objects Naming Guidelines V1.0 2008.06.28 1 相关的设计规范 3 1.1 采用有意义的字段名 3 1.2 遵守3NF 标准3NF 规定： 3 1.3 小心保留词 3 1.4 保持字段名和类型的一致性 3 2基本命名规则 3 2.1 数据库(Database)的命名 4 2.2 表(Table)的定义 4 2.3 字段命名规范: 5 2.3.1 前缀数据类型举例 5 2.3.2 数据类型 6 2.4触发器命名规范 11 2.5 存储过程命名规范 11 2.6 存储过程中的参数及变量命名规范 12 2.7 用户定义函数命名规范 12 2.8 命名中其他注意事项 12 2.9 SQL语句的编写规范 12 2.10 Rule 12 2.11主键 12 2.12外键 12 2.13索引 12 2.14 Default 13 2.15 Check约束 13 2.16 unique约束 13 3 编程结构和描述 13 3.1注释 13 3.2函数注释： 13 3.3条件执行语句if…else 14 3.4重复执行while和跳转语句goto 14 3.5书写格式 14 3.6字体 15 4触发器编程规范 15 4.1范例 15  1 相关的设计规范 1.1 采用有意义的字段名 尽可能地把字段描述的清楚些。当然，也别做过头了，比如： CustomerShippingAddressStreetLine1 虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中。每个单词的首个字母要求用大写!!!不要用下划线来连接每个单词. 1.2 遵守3NF 标准3NF 规定： A.表内的每一个值都只能被表达一次。 B.表内的每一行都应该被唯一的标识(有唯一键)。 C.表内不应该存储依赖于其他键的非键信息。 1.3 小心保留词 要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，写的一个ODBC 连接程序里有个表，其中就用了DESC 作为说明字段名。后果可想而知！DESC 是DESCENDING 缩写后的保留词。表里的一个SELECT *语句倒是能用，但我得到的却是一大堆毫无用处的信息。 1.4 保持字段名和类型的一致性 在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做“AgreeMentNumber”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。 2基本命名规则 在这里，我提出如下数据库设计的建议： 1） 如果要写代码来确保表中的行都是唯一的，就为表添加一个主键。 2） 如果要写代码来确保表中的一个单独的列是唯一的，就为表添加一个约束。 3） 如果要写代码确定表中的列的取值只能属于某个范围，就添加一个 Check 约束。 4） 如果要写代码来连接 父－子 表，就创建一个关系。 5） 如果要写代码来维护“一旦父表中的一行发生变化，连带变更子表中的相关行” ，就启用级联删除和更新。 6） 如果要调用大量的 Join来进行一个查询，就创建一个视图。 7） 如果要逐条的写数据库操作的语句来完成一个业务规则，就使用存储过程。 NOTE：这里我没有提到触发器，实践证明触发器会使数据库迅速变得过于复杂，更重要的是 触发器难以调试，如果不小心建了个连环触发器，就更让人头疼了，所以我更倾向于根本就不使用触发器。 表 1. 基本数据库对象命名 数据库对象 前缀 举例 表(Table) tb tbStudent 字段(Column) var varTitle 默认值(default) df_ df_default 视图(View) vw vwActivity 存储过程(Stored procedure) pr prDelOrder 触发器(Trigger) tr trOrder_D 索引(Index) ix_ ix_CustomerID 主键(Primary key) pk_ pk_Admin 外键(Foreign key) fk_ fk_Order_OrderType Check约束(Check Constraint) ck_ ck_TableColumn Unique约束 uq_ uq_TableColumn 用户定义数据类型(User-defined data type) udt udtPhone 用户定义函数(User-defined func