数据库设计和管理规范

 

一，总结以前数据库设计的问题

1.I SBN，

 

类型问题：

时间是varchar2, 给操作带来不变，应设为date.

数字也是用varchar2 ，这给统计带来了不方便。

 

没有使用序列，存在并发的问题的可能。

 

状态表，还不够完善，如"newbook","reprint", 没有放在状态表中。

 

存在一个数据字段有不同的数据名，如审计单位的ID, 有managerid,manageid 两种情况，给编码带来不方便。

 

* 数据访问时，有的sql 语句不太优化，操作效率有得提高。这个是自己的体会，也许不太准确。

 

1.2 GHRX,

类型问题：

数字也有用varchar 的，如数量，就有的表中是用varcher, 给统计带来了不方便。

同一个意思的数据字段在不同的表中的类型长度不一致，有的20 ，50 ，100 ；这给后面做维护带来不便。

 

存在一个数据字段有不同的数据名

 

 

 

二，以后数据库设计规范

 

1.数据类型

字符类型严格字符型；

日期类型严格日期类型；

数值类型用数字型，特殊情况特殊处理。

 

2.数据字段长度和命名

同一意义的字段在所有数据表中长度一样长，命名一样。

数据长度可以在满足需求的情况再放宽一些。

 

如学生名称字段，类型varchar2(20), 应该可以满足需求，这里可以适当加宽varchar2(50). 这样可以防止，以后来一个外国学生，他的名字就会超过20 个字符。

但要名字要起过50 字符的应该就不会有了，有了就简写。

 

3. 建辅助表

根据需要建一些辅助性的表。不在业务中使用，只是便于编程和操作。

如图书状态表，图书的状态多; 图书类型表，图书的类型多。

 

4.建表命令规则

 

4.1 表名和字段名

表名以“t_b_ ”开头，后面根据表的作用起来，采用驼峰的命令方式。

如建一张记录订单明细的表，表：t_b_orderItem ，这里item 的第一个字母要大写。

 

数据表的字段，根据字段意义取名，采用驼峰的命令方式。

如明细编号，取名：itemId, 明细名称：itemName

 

说明：

 

请参考以下：

数据表命名时对数据表分类的考虑 

业务数据表：t_d_< 系统标识>_< 表标识> 。如销售系统的合同表 t_d_SH_Contract 或 t_d_SH_ 合同；

基本编码表：t_b_[< 系统标识>]_< 表标识> 。如客户编码表t_b_Customer 或 t_b_ 客户；

辅助编码表：t_a_[< 系统标识>]_< 表标识> 。如合同类别t_a_ContType 或 t_a_ 合同类别；

系统信息表：t_s_[< 系统标识>]_< 表标识> 。如用户表t_s_User 或 t_s_ 用户；

累计数据表：t_t_< 系统标识>_< 表标识> 。如当前库存表t_t_SO_Stock 或 t_t_SO_ 库存；

结算数据表：t_c_< 系统标识>_< 表标识> 。如库存月结表t_c_SO_StockMonth 或 t_c_SO_ 库存月结；

决策数据表：t_w_< 系统标识>_< 表标识> 。如月销售统计表t_w_SH_SellMonth 或 t_w_SH_ 月销售统计；

 

注：[] 内的内容表示可选。如“t_s_[< 系统标识>]_< 表标识> ”表示t_s_SH_User 和 t_s_User 都是符合规则的。

 

业务数据表 

设有‘录入人’和‘录入日期’列，由系统自动记录。 

记录单据的表中设置“自动单据号”，由两个字符开始以区分单据类型，后跟一数字序列表示序号；自动单据号’由系统自动生成，作为主表的主键，不允许用户修改。

当有对应的纸质单据时，设置“单据号”用于记录纸质单据的单据号。

 

4.2 视图 

v_< 视图类型>_[< 系统标识>]_< 视图标识> 。视图类型参见《表的分类》。

4.3 存储过程 

p_[< 系统标识>]_< 存储过程标识> 

4.4 函数  

f_[< 系统标识>]_< 函数标识> 

4.5 触发器 

tr_< 表名>_<i,u,d 的任意组合> 

ti_< 表名>_<i,u,d 的任意组合> 

4.6 自定义数据类型  

ud_< 自定义数据类型标识>_< 数据类型>

4.7 Default 

df_<Default 标识>   

4.8 Rule

ru_<Rule 标识> 

4.9 主键  

pk_< 表名>_< 主键标识> 

4.10 外键

fk_< 表名>_< 主表名>_< 外键标识>

 

注：[] 内的内容表示可选。如“p_[< 系统标识>]_< 表标识> ”表示p_s_addUser 和p_addUser

 

 

 

 

5.命令规则应该注意事项

 

(1) 以上命名都不得超过30 个字符的系统限制。变量名的长度限制为29 （不包括标识字符@ ）。

(2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。

(3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突

(4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。

假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

(5) 缩写规则：较短的单词可通过去掉“元音”形成缩写；

较长的单词可取单词的头几个字母形成缩写；一些单词有大家公认的缩写。

 

 

6.为每张表建序列

序列只是流水号，用来区分每条记录，没有其他意义。

如一个表中主键有两个字段，可以另外加一个流水号，以流水为主键，原打算作主键的两个字段不作主键，但保留在表中。

  

 

7.建立必要的索引

建索引会影响操作（添加，修改）的效率。

对查询比较多而操作相对少的，就应该在其查询条件中用的较多的字段上建立索引，提高查询效率。

*8.每张表中是否加备用字段的问题

三，数据库管理

1. 修改表的方式

各表建好，以后作修改都要写先说明，团队里大家同意 ，后修改。因为很多操作是相互影响的。

2. 修改数据库脚本的方式

对一些数据库脚本的修改，参考下面存储过程设计规范的操作方式，作相关说明。

3. 存储过程设计规范

 

在存储过程中必须说明以下内容：

目的：说明此存储过程的作用。

作者：首次创建此存贮过程的人的姓名。在此请使用中文全名，不允许使用英文简称。

创建日期：创建存储过程时的日期。

修改记录：

修改记录需包含修改顺序号、修改者、修改日期、修改原因，修改时不能直接在原来的代码上修改，也不能删除原来的代码，只能先将原来的代码注释掉，再重新增加正确的代码。修改顺序号的形式为：log1 ，log2 ，log3 。。。，根据修改次数顺序增加，同时在注释掉的原来的代码块和新增的正确代码块前后注明修改顺序号。

对存储过程各参数及变量的中文注解。

示例如下：

 

/*

目的：根据部门与物料和会计区间查询生产现场领料汇总报表

作者：李奇

创建日期：2008-12-11

*/

 

/*

修改顺序号：log1

修改者：刘敏

修改日期：2008.12.22

修改原因：（具体原因详细描述）

*/

 

CREATE PROCEDURE [dbo].[USP_GetLMSSum]

@ProductionType int=1,     -- 生产类型（1- 自制；0- 委外加工）

@DeptID int=0,      -- 生产部门

@ItemID int=0,      -- 物料

@StartDate datetime='2002-11-26',-- 会计区间开始日期

@EndDate datetime='2002-12-25'-- 会计区间截止日期

AS

 

/*

log1 old

-- 自制领料

INSERT INTO #LMSDts

SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,

      dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,

      ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')

      AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,

      dbo.mLMS.CreateTime

end log1 old

*/

--log1 new

-- 自制领料

INSERT INTO #LMSDts

SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,

      dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,

      ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')

      AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,

      dbo.mLMS.CreateTime

--end log1 new

 

说明：

有些部分是自己实际项目开发中的体会，有的是参考网络上的资料，总结出来的，相互学习，大家共享。

 

本文出自 “ 在路上” 博客，请务必保留此出处 http://yuwenhu.blog.51cto.com/672091/136285