====>>> 数据库设计规范V2.0 <<<=====

数据库设计规范V2.0

                                                          数据库设计规范  
  1     目的  
   
        规范数据库设计。  
   
  2     概述  
   
        从数据库的设计原则     设计文档几方面论述数据库设计的规范思想及命名规则。  
   
  3     数据库应用结构  
         
        根据对一般业务系统的分析，将数据库和程序系统统一进行整体描述，展示数据库的  
   
  表之间以及与程序模块间的关系。  
   
        3.1 数据表和程序模块的分类  
   
        根据“处理特点”，将数据表和程序模块进行分类如下：  
   
        数据表分类：业务数据表、基本编码表、辅助编码表、系统信息表、累计数据表、结  
   
  算数据表、决策数据表。  
        程序模块分类：初始化、业务处理、完整性检测与修正、结算处理、统计处理。  
           
                3.1.1   数据表分类说明  
         
        业务数据表：记录业务发生的过程和结果。如，合同、出仓单、申请单、凭证。  
        基本编码表：描述业务实体的基本信息和编码。如，产品、客户、供应商、雇员。  
        辅助编码表：描述属性的列表值。如，合同类型、职称、民族、付款方式。  
        系统信息表：存放与系统操作、业务控制有关的参数。如，用户信息、权限、用户配  
   
  置信息、成本核算方式。  
        累计数据表：存放业务的当前值和累计值。如，当前库存、当前存款、累计销售、累  
   
  计支出、应收账款。  
        结算数据表：存放各个时期末的结存数。如，月末库存、月末银行存款、应收账款月  
   
  结。  
        决策数据表：存放各个时期内发生的统计值。如，月销售统计、月回款统计、出入库  
   
  统计。  
   
                3.1.2   程序模块分类说明  
   
        初始化：系统运行前对系统进行数据的初始化。如，库存初始化。  
        业务处理：业务过程的控制和结果记录。如，合同录入、费用审批、出入库。  
        完整性检测与修正：对累计数据表进行检查并自动修正。如对当前库存、当前存款、  
   
  累计销售的检查和重新计算。  
        结算处理：计算并记录各个时期末的结存数。库存月结、应收账款月结。  
        统计处理：计算并记录各个时期内发生的统计数。如，统计月销售、统计月回款、统  
   
  计出入库。  
   
        3.2   数据表间的关系  
   
        业务数据表<-->基本编码表   主-外键关系。如，合同表<-->客户编码表;  
        业务数据表<-->辅助编码表   主-外键关系。如，合同表<-->付款方式;  
        业务数据表、累计数据表、结算数据表：累计数据表=结算数据表(上期末)   +   业务数  
   
  据表(本期内发生)。如当前库存=上月末库存数+(本月入库数-本月出库数);  
        决策数据表<-->业务数据表   决策数据表的数据是由业务数据表中数据导出(统计)的；  
   
        3.3   数据表与程序模块间的关系  
               
        由一个例子(仓库管理)来说明数据表与程序模块之间的关系：  
        .   系统使用前，由初始化模块对库存数(累计数据表)和上月末库存数(结存数据表)进  
   
  行初始化；  
        .   当有入库业务发生时，由入库模块(业务处理)将入库单录入并保存到入库单明细帐(  
   
  业务数据表)中，同时将入库数累加到库存数(累计数据表)中；  
        .   定期或不定期，库存数核算模块(检查完整性检测与修正)根据上月末的库存数(结存  
   
  数据表)、本月已发生数(业务数据表)检查当前的库存数(累计数据表)是否符合，不符合  
   
  则给出提示，可手工或自动进行更正(当前库存数=上月末库存数+本月入库数-本月出库数  
   
  )；  
        .   每月初，进行上月的月结处理。月结模块(结算处理)根据上月初的库存数(结存数据  
   
  表)、上月发生数(业务数据表)计算出上月末的库存数(累计数据表)。公式为：上月末库  
   
  存数=上月初库存数+上月入库数-上月出库数；  
        .   每个月月结后，库存业务月统计模块(统计处理)统计上月的各种库存商品的入库和  
   
  出库数，便于查询和生成报表，也作为决策支持的数据基础。  
   
        3.4   数据表命名时对数据表分类的考虑  
   
        .   业务数据表：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     数据库结构原则  
         
        规定除数据库设计所遵循的范式外的一些适用原则，在遵循数据库设计范式的基础上  
   
  ，合理地划分表，添加状态和控制字段等。  
   
        4.1 辅助编码表  
   
        为了使辅助编码表能起到预期的效能，又不因过多的辅助编码表难以管理，故对辅助  
   
  编码表的使用作如下规定：  
   
        1.   当某辅助编码表的编码允许用户添加时，应设计成“独立”的数据表；否则，将不  
   
  允许用户添加编码的各辅助编码表合并成一个“通用”的辅助编码表。  
        2.   “独立”的辅助编码表与主表的列采用主-外约束保证列数据完整性。  
        3.   “通用”的辅助编码表与各主表间没有约束关系，主表列的数据完整性由列说明的  
   
  “域”来保证。  
        4.   “通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各  
   
  码表，该标识列+编码列作为该表的主键。  
        5.   对于“独立”的辅助编码表，用户只可添加新的编码和改变名称，并且不能改变一  
   
  个编码所代表的意义；对于“通用”的辅助编码表，原则上不允许用户修改，或只有限地  
   
  允许修改名称。  
         
        4.2 基本编码表  
   
        1.   基本编码表可以有如下的标识列：内编码、外编码、助记码、简称、全称。内编码  
   
  （唯一编码）作为主键有程序自动生成，用户不可见；外编码（唯一编码）由用户按某种  
   
  规则自行定义，用户可见；助记码为拼音缩，方便录入，不唯一，重码时由列表选择；简  
   
  称用于列表显示和报表，以便缩短行宽。以上的列在实现时可视情况和习惯加以删减。  
        2.   当码表的列较多且也行较多时，可将上述的标识列和常用的信息存于一个表，将其  
   
  它的信息另表存储。  
   
        4.3 业务数据表  
   
        1.   设有‘录入人’和‘录入日期’列，由系统自动记录。  
        2.   记录单据的表中设置“自动单据号”，由两个字符开始以区分单据类型，后跟一数  
   
  字序列表示序号。‘自动单据号’由系统自动生成，作为主表的主键，不允许用户修改。  
   
  当有对应的纸质单据时，设置“单据号”用于记录纸质单据的单据号。  
        3.   明细表中设有行序号，自动记录行的录入顺序。  
        4.   设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改  
   
  已有行时设置该标记；数据抽取后清除该标记。  
        5.   对于用于查询过滤条件的列，不可为空，以免行“丢失”。  
        6.   对于数值列，不可为空，“0”作为默认值。  
        7.   对于必要的“冗余”列，如客户名称，应有相应的程序保持各“冗余”列的同一性  
   
  ，以免出现异议。  
        8.   设置“过程状态”列和“记录状态”列。过程状态列用于记录如创建、审核、记账  
   
  、冲红等状态；记录状态用于记录如有效、删除等状态。  
         
  5     数据库命名原则  
   
        5.1   表名  
   
        .   业务数据表：t_d_<系统标识>_<表标识>。  
        .   基本编码表：t_b_[<系统标识>]_<表标识>。  
        .   辅助编码表：t_a_[<系统标识>]_<表标识>。  
        .   系统信息表：t_s_[<系统标识>]_<表标识>。  
        .   累计数据表：t_t_<系统标识>_<表标识>。  
        .   结算数据表：t_c_<系统标识>_<表标识>。  
        .   决策数据表：t_w_<系统标识>_<表标识>。  
   
        5.2   视图  
   
        v_<视图类型>_[<系统标识>]_<视图标识>。视图类型参见《表的分类》。  
   
        5.3   存储过程  
   
        p_[<系统标识>]_<存储过程标识>  
   
        5.4   函数  
   
        f_[<系统标识>]_<函数标识>  
   
        5.5   触发器  
   
        tr_<表名>_     (after)  
        ti_<表名>_     (instead)  
   
        5.6   自定义数据类型  
   
        ud_<自定义数据类型标识>_<数据类型>  
   
        5.7   Default  
   
        df_  
   
        5.8   Rule  
   
        ru_  
   
        5.9   主键  
   
        pk_<表名>_<主键标识>  
   
        5.10   外键  
   
        fk_<表名>_<主表名>_<外键标识>  
   
   
  附：  
   
  为了描述第一部分清楚，请下载浏览   《数据表分类描述图》  
   
  visio格式  
  http://218.242.185.84/bbs/update/20036/20221827CSDN.vsd  
   
   
  图片格式  
  http://218.242.185.84/bbs/update/20036/20222035CSDN.jpg  
  问题点数：300、回复次数：280Top

您好！  
      根据前段时间大家的努力，2.0已经完全整理完成，如果你有兴趣，您可以拷贝下来或给其他人做参考，我想对于一个数据库设计人员来说它是极具参考价值的，我再次邀请您参加这次讨论，这样它才能正确，我们将继续整理出新的版本，希望能得到您的意见！

   
  但是，正如有些朋友在前一贴中说的，现在这个规范更像是为某此行业定制的，不是特别的通用。“数据库设计规范”这人题目大了点。  
   
  也许用“xxxx   数据库设计规范”更好一些。  
   
  各位老大别骂我啊。。。。Top

19 楼Yang_（扬帆破浪）回复于 2003-06-26 11:19:50 得分 2

4.1 辅助编码表  
   
  4.   “通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各  
   
  码表，该标识列+编码列作为该表的主键。  
  --关于标识列，看不懂  
   
  --“独立”和“通用”如何取舍，应该加一条说明（最好举例）  
  Top

22 楼Yang_（扬帆破浪）回复于 2003-06-26 11:25:20 得分 2

4.3 业务数据表  
   
        4.   设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改  
  已有行时设置该标记；数据抽取后清除该标记。  
  --好像不好操作  
   
        8.   设置“过程状态”列和“记录状态”列。过程状态列用于记录如创建、审核、记账  
  、冲红等状态；记录状态用于记录如有效、删除等状态。  
  --“记录状态”经常并不需要  
   
  Top

先做个记号Top

29 楼blueshrimp（下着沙-软件民工）回复于 2003-06-26 11:50:36 得分 2

小丸子问老师：“我奶奶八十了能怀孕吗？”  
  老师说：“不能。”  
  “那我姐姐十八能吗？”  
  “能。”“那我能吗？”  
  “不能，你还小。”  
  坐在旁边的小新说：“你看，我说没事儿吧！”Top

33 楼BlueskyWide（谈趣者）回复于 2003-06-26 12:21:22 得分 1

to   No.2:  
  看了一遍，不错，给个建议：  
  1.加上"行业类别"和"行业名称"。  
  2.因为再通用的规范，不同的行业也有其特殊性,应加上"特殊说明区"。  
  Top

39 楼19191919（小楼别筑）回复于 2003-06-26 12:51:00 得分 1

偶也认为更适合某种行业的规范。不错，仔细看看先。Top

41 楼AechoJohn（江江）回复于 2003-06-26 12:56:54 得分 1

对。  
  大致的描述应是这样的，用到不同的领域不同的项目和产品时，还要适势做些变动。Top

42 楼jeck_zhou（大海）回复于 2003-06-26 12:57:15 得分 1

搂主这么热心，我也贡献一点。  
   
  一、   概述  
  为了提高编码的效率和标准化程度，增强代码的可读性，特制定本规范作为公司软件开发人员设计数据库时的开发规范。本规范规定数据库中各种对象的命名规则及代码书写规则。  
  除非特别说明，本文中的数据库都是指目前的主流关系型商业数据库系统，如Informix，DB2，Oracle，Access等。  
  二、   命名规范  
  1、 命名规则说明  
  对象命名的格式如下：  
  type_[desc]_name…  
  其中：  
  l 下划线(_)： 为名称的一部分，用于提高命名的可读性；  
  l 类型(type)： 用于标识对象的类别，用正常字体表示；  
  l 修饰符(desc)： 用于描述对象的某种属性，可选；  
  l 名称(name)： 此部分由用户用具体的词代替；  
  l 中括号([])： 表示此部分为可选项目。  
  l 小数点(.)： 表明此部分长度可变。  
  2、 数据库设计中涉及的对象及命名规范  
  以下给出在数据库设计中经常使用到的对象及其命名规范：  
  2.1、 数据库设备(Database   Device)  
  l 名称  
  dev_xxx  
  l 说明  
  dev：表明这是一个数据库设备名称。  
  xxx：   表明该设备的用途，如：  
                log：     用于事务日志  
                dat：   用于数据和索引  
  l 举例  
  dev_dat_1  
  dev_dat_2  
  dev_log_1  
  如果该设备是镜像设备，应采用如下命名方式，在设备名称后加“_mir”：  
    dev_dat_1_mir             dev_dat_2_mir       dev_log_1_mir    
  2.2、 数据库(Database)  
  l 名称  
  db_dddd_vvvv  
  l 说明  
  db：表明这是一个数据库名称。  
  dddd：   是一个有意义的描述  
  vvvv…：   版本或环境描述。如：  
  dev(开发)  
          test(测试)  
          prod(产品)  
          train(培训)  
  l 举例  
  db_travel_dev  
  db_travel_test  
  db_operations_prod  
   
  2.3、 表(Table)  
  l 名称  
  [t][tab]_[desc]_tttt…  
  l 说明  
  t或者tab：表明这是一个表名称。  
  desc：   对表的某种属性的描述，比如对于有多个子系统的开发项目，应在相应的子系统所用的表(table)前加上相应的子系统缩写作为描述符，   在公用表前加描述符pub_；对于小型系统，可省去此项；  
  tttt：   表的意义描述。  
  l 举例  
  t_pub_user  
  t_book_publisher  
  tab_pub_user  
  tab_bank_service  
  2.4、 字段(Field   or   Column)  
  l 名称  
  f_[type]_tttt…  
  l 说明  
  f：表明这是一个字段名称。  
  type：可选，表明字段类型，字符型为c，整型为i，逻辑型为b，货币类型为m,浮点型为f，日期型为d，时间型为t，二进制为bl；由于各种数据库系统都有自己定义的数据类型，因此此项为可选，不做强制要求；具体要求在具体项目的开发中进行规定。  
  tttt：   对字段属性的有意义的描述，可以用英语单词、单词缩写、汉语拼音、字段实际含义的拼音缩写等；  
  l 举例  
  f_name(姓名)  
  f_c_name  
  f_xm(姓名)  
  f_grp_id(组标识)  
  2.5、 索引(Index)  
  l 名称  
  idx_tttt…  
  l 说明  
  idx：表明这是一个索引名称。  
  tttt：   对索引属性的有意义的描述；  
  l 举例  
  idx_usersid  
  2.6、 视图(View)  
  l 名称  
  v_tttt…  
  l 说明  
  v：表明这是一个视图名称。  
  tttt：   对视图属性的有意义的描述；  
  l 举例  
  v_special_user  
  v_cancled_order  
  2.7、 触发器(Trigger)  
  l 名称  
  trg_[d][i[[u]_tttt…  
  l 说明  
  trg：   表明是一个触发器  
  d，i，u：     表明触发器类型(Delete，Insert，Update)定义；注意书写顺序为d、i、u，而不能有任意逆转书写  
  tttt…：   是一个表(Table)的名称，表明触发器所在的表。  
  l 举例  
  trg_iu_air_segment  
  trg_d_group_client  
  l 创建触发器的脚本文件命名  
  trgname.sql  
  其中trgname为触发器名称，如：  
  trg_iu_air_segment.sql  
  2.8、 约束(Constraint)  
  l 名称  
  cns_tttt…  
  l 说明  
  cns：   表明是个约束  
  tttt…：   描述；  
  l 举例  
  cns_contid  
  2.9、 存储过程(Stored   Procedure)  
  l 名称  
  sp_tttt…  
  l 说明  
  sp：   表明是个存储过程  
  tttt…：   有意义的描述；  
  l 举例  
  sp_AddUser  
  l 创建存储过程的脚本文件命名  
  spname.sql  
  其中spname为存储过程名称，如：  
  sp_AddUser.sql  
   
  三、   数据库说明书格式  
  数据库说明书用来说明数据库中各个对象的详细信息，包括数据库表、字段、索引、视图、触发器、约束等。说明书示例如下：  
  1、 tab_PhysicalCheck(健康评估－体征和检查表)  
  l 功能描述：存放用户的体检数据。  
  l 字段说明：  
  字段名称 字段类型 说明 备注  
  f_id Integer 唯一标识  
  f_detid Integer 评估总表标识 连接健康评估总表中的f_hp_id  
  f_tw integer 体温  
  f_mb integer 脉搏  
  f_hx integer 呼吸频率  
  f_shg integer 身高  
  f_tzh integer 体重  
  f_zhfhl single 脂肪含量  
  f_shsy integer 收缩压  
  f_shzhy integer 舒张压  
  f_chtxb char(100) 查体印象－胸部  
  f_chtfb char(100) 查体印象－腹部  
   
  l 索引  
  索引名称 包含字段 索引类型  
  idx_hpcid f_id 主键  
  idx_other f_tw+f_mb 唯一索引  
   
  l 视图  
  l 触发器  
  l 约束  
  Top

44 楼gmlxf（烛光）回复于 2003-06-26 13:05:16 得分 1

加上***数据库设计  
  不是很通用的，应该是某行的设计规范Top

46 楼bzszp（SongZip）回复于 2003-06-26 13:13:54 得分 1

已经做得很全面了也很实用，大力辛苦了  
  呵呵  
  大家如果作开发的话，应该清楚，即使需求分析做得如何好，  
  难免在开发或实施过程中修改表结构  
  因此应当在后面增加一个，数据库修改纪录  
  纪录什么时间、哪个部门、哪个表、修改内容、修改备注等信息  
   
  Top

51 楼RomanticProgrammer（) 兰企鹅||南极俺最帅 (）回复于 2003-06-26 13:38:55 得分 1

感谢楼主。  
  我正在作数据库方面的东西。准备好好研究一下这个帖子。Top

53 楼lihonggen0（李洪根，MS MVP，标准答案来了）回复于 2003-06-26 14:08:52 得分 1

 
   
  数据库定义规范  
  开发数据库应用，当然少不了幕后的英雄数据库，对于日益膨胀的信息，用户对数据库的要求越来越大，导致了数据库结构设计上的复杂程度不断增加，所以，要规范数据库的设计。  
  1.数据库(Database)的定义  
  数据库名的定义：  
  数据库名称   =   "db"   +   数据库内容标识（首字大写）  
  2.表（Table）的定义  
  凡是表的定义，在表所表示的内容前必须加上前缀"tb"。  
  表命名定义：  
  表名称   =   "tb"   +   表内容标识（首字大写）  
  3.字段（Field）的定义  
  字段是数据库中的用途最广泛的，它的类型非常多，所以必须加类型前缀来标示它的类型。  
  字段命名定义：  
  字段名称   =   字段类型前缀   +   字段内容标识（首字大写）  
  类型前缀见下表：  
  字段类型 字段类型前缀  
  "binary" "bin"  
  "bit" "bt"  
  "bitmap" "bmp"  
  "bool" "bl"  
  "byte" "bt"  
  "char" "c"  
  "date" "d"  
  "datetime" "dt"  
  "decimal" "dc"  
  "float" "f"  
  "image" "img"  
  "int" "i"  
  "long   binary" "lbin"  
  "long   characters" "lc"  
  "long   int" "li"  
  "long   float" "lf"  
  "long   var   characters" "lvc"  
  "money" "mn"  
  "multibyte" "mbt"  
  "nchar" "nc"  
  "ntext" "ntxt"  
  "numeric" "n"  
  "nvarchar" "nvc"  
  "ole" "ole"  
  "real" "rl"  
  "serial" "no"  
  "short   float" "sf"  
  "short   int" "si"  
  "smalldatetime" "sdt"  
  "smallint" "si"  
  "smallmoney" "smn"  
  "text" "txt"  
  "time" "t"  
  "timestamp" "ts"  
  "tinyint" "ti"  
  "uniqueidentifier" "uid"  
  "varbinary" "vbin"  
  "varchar" "vc"  
  "variable   multibyte" "mbt"  
  4.存储过程（StoredProcedure）的定义  
  存储过程主要涉及表中字段的添加、更新、删除，在命名时必须用前缀来标识存储过程的这些主要功能。  
  存储过程的命名定义：  
  存储过程名称   =   存储过程功能前缀   +   存储过程内容标识（首字大写）  
  前缀定义见下表：  
  存储过程功能 存储过程功能前缀  
  添加 "ap"  
  更新 "up"  
  删除 "dp"  
  查询或涉及比较多的功能 "op"  
  5.触发器（Trigger）的定义  
  触发器的命名定义：  
  触发器名称   =   "tg"   +   触发器内容标识（首字大写）  
  6.视图(View)的定义  
  视图的命名定义：  
  视图的名称   =   "vw"   +   视图内容标识（首字大写）  
  7.图表(Diagram)的定义  
  图表的命名定义：  
  图表的名称   =   "dg"   +   图表内容标识（首字大写）  
  8.SQL语句的编写规范  
  数据库中存储过程和触发器中涉及大量的SQL语句，对SQL语句的编写规范如下：  
  • 关键字大写：  
  在SQL语句的编写中，凡是SQL语句的关键字一律大写，如：SELECT、ORDER   BY、   GROUP   BY、   FROM、   WHERE、   UPDATE、   INSERT   INTO、   SET、   BEGIN、   END   ......    
  • 缩格：  
  但凡SQL程序可加容器关键字BEGIN...END的内容都要缩格，他的内容都要左对齐、类似程序中的函数与子程序。    
  • 其他的编写格式参照编程规范    
   
  Top

59 楼pengdali（）回复于 2003-06-26 14:51:47 得分 0

to   nonononono  
      在我们的命名方法里，前缀的字符有一个也有两个，如果在表的命名方法里将起始的t和随后的字符间没有“_”，则与两字符前缀的命名将难以识别  
   
  to   spring_ok(SpringDotNet)    
      "许用“xxxx   数据库设计规范”更好一些。"  
      Re:我们的规范是面向各行业的，我们举的例子只是为了说明问题，并不代表是针对特定行业或特定项目的，有一点就是，我们是针对MIS系统设计的，可能不适应MIS以外的项目，但与行业无关。就像一个开发平台可以开发不同行业的不同程序一样。实际上，MIS系统有很多共性的。  
   
  to   Yang_(扬帆破浪)    
  “通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各  
  码表，该标识列+编码列作为该表的主键。  
  --关于标识列，看不懂  
  --“独立”和“通用”如何取舍，应该加一条说明（最好举例）  
   
        Re:对于相对固定不变的辅助编码表，或者说不允许用户修改的辅助编码表，这种表相对很小，为了减少表的个数，将这些编码表合并到一起，就称为“通用”，为了区分包含的各编码表，就需要一个标识列来区分，为了保证每个子表编码的相对独立，其主键应为标识列+编码列。  
   
   
  设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改  
  已有行时设置该标记；数据抽取后清除该标记。  
  --好像不好操作  
   
  Re:使用触发器就可以使得除大批量插入外的所有插入操作和更新操作准确地更新标记，并且实现简单。  
   
        8.   设置“过程状态”列和“记录状态”列。过程状态列用于记录如创建、审核、记账  
  、冲红等状态；记录状态用于记录如有效、删除等状态。  
  --“记录状态”经常并不需要  
   
  Re:   此中的删除代表逻辑删除，使我们通常所说的“作废”，这与编程习惯有关。设置两个状态列是为了记录被作废或删除后，可以保留“过程状态”，用以识别记录被处理的过程。  
  Top

64 楼pengdali（）回复于 2003-06-26 16:10:29 得分 0

to   BlueskyWide(谈趣者)    
      1.加上"行业类别"和"行业名称"。  
      2.因为再通用的规范，不同的行业也有其特殊性,应加上"特殊说明区"。  
   
  Re:因为行业太多，无法考虑到其特殊性，只能将比较通用的部分加进来，个人在具体的项目里进行取舍  
   
  to   lihonggen0(李洪根,用.NET，标准答案来了)    
  很好，特别是有关存储过程的命名，有新意，谢谢Top

69 楼shenanigan（宝宝）回复于 2003-06-26 17:23:23 得分 1

拼音的确不适用～还是用英文或者英文缩写为妥。  
  而且是全部的，否则有点不伦不类了Top

70 楼pengdali（）回复于 2003-06-26 17:32:07 得分 0

to   OpenVMS(半知半解)   shenanigan(慈禧太后)    
        用中文、用拼音、用英文和用数字命名，我们在规范中并不作规定，可以根据个人喜好和具体项目的要求自行定义。Top

71 楼pengdali（）回复于 2003-06-26 17:32:15 得分 0

to   OpenVMS(半知半解)   shenanigan(慈禧太后)    
        用中文、用拼音、用英文和用数字命名，我们在规范中并不作规定，可以根据个人喜好和具体项目的要求自行定义。Top

72 楼xiong1979（太空一号）回复于 2003-06-26 17:43:40 得分 1

拼音的确不适用～还是用英文或者英文缩写为妥。  
  Top

73 楼babytong（你是天上乌鸦飞啊飞|我是地上黄狗追呀追）回复于 2003-06-26 18:08:04 得分 1

不管怎么弄，在定义前要有一个文档参照表  
  如下格式  
  数据项前缀  
  tb_——表名  
  v_——视图  
   
  tb_news——新闻发布系统相关表  
   
  Top

74 楼spring_ok（广州泰能软件）回复于 2003-06-26 18:20:48 得分 1

To   pengdali(大力   V2.0)   (   )   :  
   
      "许用“xxxx   数据库设计规范”更好一些。"  
      Re:我们的规范是面向各行业的，我们举的例子只是为了说明问题，并不代表是针对特定行业或特定项目的，有一点就是，我们是针对MIS系统设计的，可能不适应MIS以外的项目，但与行业无关。就像一个开发平台可以开发不同行业的不同程序一样。实际上，MIS系统有很多共性的。  
   
  是的，没错。我其实也是这个意思，可能表达上有些误导。Sorry!  
  由于我主要从事的都是MIS系统以外的项目，所以觉得这个规范不太容易套用到我所参与的项目中。要在我所做的项目中区分"业务数据表       .   基本编码表：       .   辅助编码表：       .   系统信息表：       .   累计数据表：       .   结算数据表：       .   决策数据表"   是比较困难的。  
   
  但是，这个规范的确能让人学到很多新的知识。  
   
  另外，我认为还应该补充数据表建立的原则以及表中字段的设计规范相关的内容，例如,如何分析来确定你的系统需要哪些表？如何设计相关的表中的字段来满足第N范式（一般应该要求尽量满足第三范式吧）。  
   
  Top

80 楼OpenVMS（半知半解）回复于 2003-06-26 23:33:10 得分 1

个人认为表名和存储过程前加前缀T_以及P_，似乎不很好，因为他们和其他的数据库对象在不同的范围，而且使用频繁，脚本文件名另当别论，建议用业务缩写或子系统名作前缀更好些（也可不要，直接用在数据库名，脚本，外部文件名），简洁表达其用途是目的。Top

81 楼net_steven（素狼（W））回复于 2003-06-27 00:28:37 得分 1

很好，大力！比较完整总结了一个MIS系统的一般架构。  
  补充一点，对业务数据，特别是关键业务数据的操作，应该建立一套审计（audit）表，来  
  保留删改的痕迹，结构基本与业务表一致。体系上可以隶属业务表，也可独立算做一个审计系列。目的主要是因应管理的需要。大多数应用都会有这个要求，作为一个完善的系统也应该  
  有这部分内容。Top

88 楼sunhans（大兵）回复于 2003-06-27 12:03:16 得分 1

大力为中国程序员开了好头，大家集思广益，进而建立一个公共论坛来管理类似的规范，一定能提高我们中国软件业的水平！Top

89 楼pengdali（）回复于 2003-06-27 12:06:09 得分 0

to     spring_ok(SpringDotNet)    
   
  另外，我认为还应该补充数据表建立的原则以及表中字段的设计规范相关的内容，例如,如何分析来确定你的系统需要哪些表？如何设计相关的表中的字段来满足第N范式（一般应该要求尽量满足第三范式吧）。  
   
      Re:   数据表建立原则及表中字段的设计规范内容太多，我们在结构原则中只能提出初步的建议，很多细节包含个人的设计经验，需要大家逐步完善。至于第N范式的问题，许多书上都有介绍，对于具体项目如何设计数据库并满足第三范式，这与个人的经验有关，大家可以交流，但我觉得这不是我们的规范要制定的内容。  
   
  to   OpenVMS(半知半解)    
        个人认为表名和存储过程前加前缀T_以及P_，似乎不很好，因为他们和其他的数据库对象在不同的范围，而且使用频繁，脚本文件名另当别论，建议用业务缩写或子系统名作前缀更好些（也可不要，直接用在数据库名，脚本，外部文件名），简洁表达其用途是目的。  
       
        Re:如果确认命名不会冲突，节省不必要的前缀确实不错，但业务缩写或子系统名作前缀是必要的，特别当表很多时。  
   
  to   net_steven(吃素的狼（瘦了）)  
     
    对业务数据，特别是关键业务数据的操作，应该建立一套审计（audit）表，来  
  保留删改的痕迹，结构基本与业务表一致。体系上可以隶属业务表，也可独立算做一个审计系列。目的主要是因应管理的需要。大多数应用都会有这个要求，作为一个完善的系统也应该有这部分内容。  
   
  Re:好习惯，对重要的业务数据确实需要，我觉得对于重要的基本编码表如客户表，也要有相应的设计，以便追踪客户资料的修改，我们在实际设计中已有这样的需求。  
   
       
     
   
     
   
   
  Top

90 楼pengdali（）回复于 2003-06-27 12:06:27 得分 0

to     spring_ok(SpringDotNet)    
   
  另外，我认为还应该补充数据表建立的原则以及表中字段的设计规范相关的内容，例如,如何分析来确定你的系统需要哪些表？如何设计相关的表中的字段来满足第N范式（一般应该要求尽量满足第三范式吧）。  
   
      Re:   数据表建立原则及表中字段的设计规范内容太多，我们在结构原则中只能提出初步的建议，很多细节包含个人的设计经验，需要大家逐步完善。至于第N范式的问题，许多书上都有介绍，对于具体项目如何设计数据库并满足第三范式，这与个人的经验有关，大家可以交流，但我觉得这不是我们的规范要制定的内容。  
   
  to   OpenVMS(半知半解)    
        个人认为表名和存储过程前加前缀T_以及P_，似乎不很好，因为他们和其他的数据库对象在不同的范围，而且使用频繁，脚本文件名另当别论，建议用业务缩写或子系统名作前缀更好些（也可不要，直接用在数据库名，脚本，外部文件名），简洁表达其用途是目的。  
       
        Re:如果确认命名不会冲突，节省不必要的前缀确实不错，但业务缩写或子系统名作前缀是必要的，特别当表很多时。  
   
  to   net_steven(吃素的狼（瘦了）)  
     
    对业务数据，特别是关键业务数据的操作，应该建立一套审计（audit）表，来  
  保留删改的痕迹，结构基本与业务表一致。体系上可以隶属业务表，也可独立算做一个审计系列。目的主要是因应管理的需要。大多数应用都会有这个要求，作为一个完善的系统也应该有这部分内容。  
   
  Re:好习惯，对重要的业务数据确实需要，我觉得对于重要的基本编码表如客户表，也要有相应的设计，以便追踪客户资料的修改，我们在实际设计中已有这样的需求。  
 

101 楼Yang_（扬帆破浪）回复于 2003-06-27 18:05:07 得分 1

呵呵，No.100  
   
   
  “通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各  
  码表，该标识列+编码列作为该表的主键。  
  --关于标识列，看不懂  
  --“独立”和“通用”如何取舍，应该加一条说明（最好举例）  
   
        Re:对于相对固定不变的辅助编码表，或者说不允许用户修改的辅助编码表，这种表相对很小，为了减少表的个数，将这些编码表合并到一起，就称为“通用”，为了区分包含的各编码表，就需要一个标识列来区分，为了保证每个子表编码的相对独立，其主键应为标识列+编码列。  
   
  Re:Re:这样的“通用”我觉得没有必要，增加了表的复杂度，降低了范式，也增加了出错机会，唯一的好处是辅助编码表的个数少了，辅助编码表本来就不会很多，而一般大型数据库对表的数量基本可以算没有限制。  
   
   
  设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改  
  已有行时设置该标记；数据抽取后清除该标记。  
  --好像不好操作  
   
  Re:使用触发器就可以使得除大批量插入外的所有插入操作和更新操作准确地更新标记，并且实现简单。  
   
  Re:Re:一般标记字段的取值范围很小，不好加索引，考虑性能，应该减少标记字段的数量。  
      存档我觉得可以有其他方法，不必做规定。  
   
  Top

111 楼appletalk（青龙瓦当）回复于 2003-06-29 14:21:03 得分 1

请教各位前辈"  
  如果用中文来命名数据库规范体系,是否有什么缺点或隐患呢?Top

117 楼pengdali（）回复于 2003-06-30 09:00:58 得分 0

to   Yang_(扬帆破浪)    
      这样的“通用”我觉得没有必要，增加了表的复杂度，降低了范式，也增加了出错机会，唯一的好处是辅助编码表的个数少了，辅助编码表本来就不会很多，而一般大型数据库对表的数量基本可以算没有限制。  
   
  re:同意  
   
  Re:Re:一般标记字段的取值范围很小，不好加索引，考虑性能，应该减少标记字段的数量。  
      存档我觉得可以有其他方法，不必做规定。  
   
  re:同意，谢谢！！  
  Top

121 楼CSFish（海里唯一的鱼）回复于 2003-06-30 20:50:11 得分 1

学习  
   
  给楼主一点建议：  
   
  表名、视图和存储过程命名最好不要用太多“_”，不合规范Top

122 楼qiubolecn（来自差生市）回复于 2003-06-30 23:32:41 得分 1

楼主对表的概述非常的详细，但是否需要对视图也进行这样的一些补充呢。  
   
  在我实际的使用当中，对表的规划远远不及视图规划重要。  
   
  我们的业务逻辑都是封装在视图下，任何对表的陈述都是非常冗余的，因为在进行  
  数据建模的初始，我们与程序员所交互的都是逻辑视图，而这些逻辑视图对程序员非常的  
  实用，但对我们数据库设计人员来讲实在是糟糕，由此带来很多的问题，如结构不合理  
  数据冗余，数据一致性得不到保证等。  
  万幸SQL   SERVER对视图的支持非常的好，另外还可以利用函数来扩充视图的功能。  
  因此我们的工作重点在视图的理解上。虽然这会带来逻辑结构的复杂性以及架构和维护的复杂性，但在对于一些数据比较大（一个月有1G数据）量的大弄数据库来说，这些是极其有必要性的。  
  我对我们工作中的一些情况也作一下描述。  
   
  我们的视图在构架上分为以下几类，一类是静态视图，一类是动态视图，静态视图非常容易理解，就是创建以下不再进行改变的视图，我们平时工作的绝大部分都属于此部分。动态视图是我抽象出来的，例如我们在对存储过程进行编写时，经常会遇上表名或字段名不确定或是由其它的系统表产生的。这样会让我们在用SQL的时候必须用exec来进行执行，因为这样会给程序调试带来极大的不必，所以，我们将一些非常关键的基础数据用动态视图来进行实现，当然前提是建立动态视图及其引用不会带来太大的性能牺牲。  
   
  我们的视图在用途上分为以下几类  
  一类是基础数据，为了更接近3nf，增加一臻性，这是非常有必要的，如我们将名称与编号分开存储，当需要引用大量的名称时，我们就必须关联多个表，对于程序设计者来说，他们是非常讨厌这个的，而且，物理表在实施后期也有可能会改动（一般极少），综合这些，大家宁愿用视图进行数据读取。  
  二类是查询用，我见过最糟糕的程序员所写的程序就是所有显示给用户的表名，列，及其中文都是固定的，对于一些特殊定帛的软件，在用户需求非常详细的情况下是可以的，但这一般是不丈可能的，因此将查询进行用视图表视是非常有必要的。  
  三类是系统用，如我们定义一些规则，当某字段的dQiuboleRead属性为true时，从基本视图中读取数据，因为某字段未固定，或有可能会添加，因此，我们不能从基本表中读取数据，而得从视图里面读。  
   
  对所有上述的命名都不好统一，除非你是在开展一个新的项目，并且你项目组的成员没有合作过，否则任何新的命名会带来他们的反感，并且会给上个项目到本个项目的维护困难加大。  
   
  顺便再说一下我们平时工作的一些小技巧。  
  我们的任何可执行数据区（存储过程，触发器）都有两种模式，一是发布模式，二是调式模式，在调式模式会将其状态等信息进行记录。  
   
  系统表都有一个触发器用来跟踪谁对它进行改变或试图改变。  
   
  系统完成时的表及视图最少会比规则时多1/5  
   
  当系统数据超过1G时就好好规则一下你的文件存储方式。  
   
  当系统表或基本表超过1/5时请不要再随意增加你的表了。  
   
  任何辅助表都是可以进行压缩的，当表字段意思相差2－5个字段时最好用同一个辅助表。  
  （辅助表引用楼主的用法）  
   
  一点愚见，欢迎大家指正。qiubole随笔Top

125 楼pengdali（）回复于 2003-07-01 12:11:46 得分 0

to   CSFish(海里唯一的鱼)    
        用“_”可以清晰各分段的功能，特别当表很多时，实际上对于命名只要符合习惯，贯彻始终就可以了。  
   
  to   qiubolecn(来自差生市)    
        非常同意，我也非常喜欢用视图，它是保证数据库规范化设计，又可以方便使用的法宝，许多反对规范化设计的人往往就是因为太少使用视图，没有真正体会到你所说的三类用途。实际上视图的设置对于数据库的设计影响很大，并且有太多的用法和用途，有时间希望能多多探讨。Top

143 楼itzero（零点）回复于 2003-07-07 17:27:25 得分 1

好贴！  
   
  最好和数据仓库一起综合考虑一下]！Top

154 楼stwx（stwx）回复于 2003-07-09 22:21:41 得分 1

建点意见,请大家指教.   很多行业:业务数据表多为明细表,   也是整个系统中数据量最大的表.   考滤到大数据量时的系统性能,就将业务数据表加一标识字段,拆分为多个表存放,再过通分区视图(或分布式分区视图)   访问整个业务数据表,这有利于系统不断扩容.Top

155 楼stwx（stwx）回复于 2003-07-09 22:33:37 得分 1

结算数据表大多是从业务数据表统计出来,所以比起业务数据表要小得多.   (大多是多业务数据表   group   by   而成),所以依据实际需要进行设计.  
   
          设计结构时,不但是命名,数据完整性,要考滤,还要有一个解决数据量日益增大时,  
  数据查询的实时性,查询速度之间的问题.       (有些系统牺牲数据的实时性改善系统性能)  
   
   
  Top

158 楼wyoyo（我的眼睛在闪闪发光）回复于 2003-07-10 09:11:58 得分 1

本人在用一个很成熟的服装管理系统，却是“数据库盲”，可惜！希望大家多多帮忙，一个成熟的数据库对大家来说也是一个最好的学习机会，而你们的帮忙对我来说也是最好的一次机会，所以，不知能否互相帮忙！email:chenmangmang@hotmail.com;qq:68695100Top

160 楼pengdali（）回复于 2003-07-11 10:49:28 得分 0

to   stwx(stwx)  
        好建议，对于分区视图在大的数据库应用中将大大改善系统性能，我们有必要就视图的用途及使用技巧进行一些讨论   。  
     
  Top

202 楼54yj（54yj）回复于 2003-07-29 09:56:25 得分 1

有一定的实用价值，感谢！  
  如果能有一个通用数据库设计模式的讨论和整理就好了  
  现在也有一些这方面的东东，可是还是太难得了。  
  严重建议对组织机构、权限管理、历史版本、各行业业务等进行数据库设计模式得讨论和整理！Top

208 楼BlueskyWide（谈趣者）回复于 2003-07-29 18:00:07 得分 1

今后中国要开发自已的操作系统的话,  
  强烈推荐大力成为其中一员,并担任数据库工作组组长!  
  Top

243 楼zzzl（不拉拉链）回复于 2003-08-15 14:18:02 得分 1

1.   设有‘录入人’和‘录入日期’列，由系统自动记录。  
  没有这两个列系统记在哪里？Top

244 楼zhusongdong（大漠孤烟）回复于 2003-08-15 20:20:56 得分 1

非常感谢大力兄的无私奉献，为大伙儿带来实用的知识！向大力兄致敬！  
  想再请教大力兄一个问题！  
  要求能以任意时间段查询库存汇总表与库存明细表如下所示：  
  库存汇总表  
  起始日期：2003-1-1   终止日期：2003-3-14　仓库名称：成品仓  
  货品编号｜货品名称｜期初数量｜期初金额｜收入数量｜收入金额｜发出数量｜发出金额｜期末数量|期末金额　  
  相关数据库如何设计查询速度会比较快些！盼复！！！Top

251 楼iloveinfo（robert）回复于 2003-08-17 20:18:22 得分 1

我可以上载文件吗？大家可以看看我们公司的数据库设计规范，相对来说，比楼上的通用一点点。顺便给楼上的规范提几点意见，不要见怪：  
   
  1）与业务的东东耦合度太高，有的东西不需要在这里面体现，数据库设计规范就仅是数据库设计规范，与别的东西没有关系，要体现的话在别的文档体现，如数据表与程序模块间的关系等内容；  
   
  2）没有版本的概念，也就是数据库内容的设计不是一天定下来的，可能要随着业务和代码的开发，数据库内容也在变，如何体现出来变化，没有涉及？  
   
  3）没有团队的概念，有很多东西是需要多人参与的，不同的人利用这份文档的角度不一样，如果有多人参与的话，我不知道象这份涵盖这么多具体的业务概念的东西在哪个阶段、什么样的人能做得出来，如果业务变化的话，根据这份文档设计的系统不知道要改多少地方；在有些内容还定不下来的的时候，其它人能不能利用这份文档开始搭框架和原型，搭了以后又有多少可以利用？数据库设计是很多东西的基础，如果这份东西做的不好话，如果您是项目负责人，改来改去，大家都会跟着您累死。  
   
  4）提一些建议：1.现在都是强调专门化和团队协作，考虑什么东西都要象个做系统的思维，自己好用是一方面，如何做到把一个庞大的系统工作细划，每做完一块，它就是一个相对完整的工作，即使它改了以后，也要尽可能影响小，而不是动不动就是整个系统与之相关的东西都要改动一次；2.合作是必要的。也就是说不要让某些文档承载太多的东西，否则很多人都要等米下锅，某些人累得半死，某些人闲死。  
   
  总的来说，这份数据库设计我看来是聊胜于无，算60分，也算对楼上的积极主动的进行总结的精神表示赞赏，有些话难听一点，有则改之，无则加勉。  
  Top

255 楼iloveinfo（robert）回复于 2003-08-19 11:57:38 得分 1

有空翻了一下前面的帧子，看到楼上几位提到了关于审计的内容，有几点感触：  
   
  （1）是不是大家对管理逻辑与业务逻辑没有区分的概念？审计的东西我理解就是属于管理的逻辑，业务逻辑就是与业务的逻辑，它们之间是相辅相成的，这时候一定有朋友会问，这样进行数据库设计，加上审计表的思路有问题吗？我的回答是：有，而且相当有问题。第一，您能想到审计表，就说明要不是您接触过许多项目用户都提出这个需求，要不就是您比用户想到更多，也就是说至少有一点您是认可的：这部分内容是必要的，除非这个系统是非常小的或者用户需求不变化。如果这样的前提下，也就需要有专门一个的模块（系统或平台）来做这部分工作，把很多工作交给这个专门的部分来完成，因为加审计表是数据库级别的，也可能是某个人或某几个人的做法，变化了以后谁来维护？又去修改审计表？审计表不能满足用户业务需求后，直接改审计表结构？这么下去的话，您做了100个项目或者系统后，天天做维护都做不完，何谈接新项目？应该有一个专门的平台去做管理，而且是有界面的，所有的管理逻辑都通过界面，从建模型开始，把管理的内容模型化，变成可管理的内容，这样才基本上从理论上来说（我们是已经实现了，而且在大量的项目中实用）可以做到管理逻辑与业务逻辑分离，再加上一些如数据与界面分离等思想，系统才有点意思，如果只是一堆代码堆在那里，不考虑维护和升级的成本，以及隐藏在其中的由于没有规划和协作、标准规范的原因而带来的只能由原始开发人员（甚至是高级的一个月拿1万2万的人员）进行维护和修改，一旦他们烦透这种工作和生活方式，一走了之的高额人员成本，您觉得自己做的事情有意义吗？我不是说您做的东西档次低，只是想表达作为一个程序员，我自己做不到，至少我也应该知道哪种境界是我们追求的境界。  
   
  （2）是不是大家在开发的时候，都没有一个处理管理逻辑的平台在做支撑？我的意思说如果涉及到角色、资源和权限的时候，如果您需要直接在代码里写上这部分的控制代码或者您即使有一些通用的模块，但是不成体系，也就是说您开发的这个系统与那个系统，这通用的模块也是不通用的，里面有很多代码变化了，只要是这样，就说明管理逻辑在您的心目中地位还不重要，难道您没有感觉您的大量的维护工作中或者您感觉到用户的用户漫延得让您感到项目结束遥遥无期时，其实很多都是管理的东西在不停做变化，并不是您实现不了某业务功能。Top

276 楼eminena（俄罗斯方块）回复于 2003-09-10 08:18:00 得分 1

 
          几乎,每隔2~3天,我就会看这个贴子,只有一个感觉:爽!  
   
          前段时间,也想说几句补充,怕说不好,又认为,可能有高手说出说想说的,所以没动手.  
  今天,还是班门弄斧吧！  
   
          关于应用程序的包装：  
   
          我要说的是狭义上的包装：应用的许可使用。  
          也许，大家认为，应用的许可使用，只需使用加密、序列号、……等手段实行，但大家忽略了数据库应用的特点。  
          我认为，充分发挥数据库的功能，设计一个许可权验证表，在打开应用的时候进行验证。  
          许可权验证表可以有多层次：  
   
          1、整个应用许可验证  
          2、分模块许可验证  
   
          对应用许可的验证，可以把应用单位的名称作为验证字，包装时，写入验证表。（验证码以某种加密方式在应用开发阶段生成）  
          模块许可验证，可以由于应用单位自行控制。  
   
          这样，即提高了应用的通用性（甚至不用改动代码，只用修改相应的配置文件（如单位名称）），又防止了应用的未授权使用。  
   
          而且，这样的许可权验证表可以建立在系统库中，提高通用性！Top

相关问题

• 数据库设计有什么规范？
• 请问：有哪位朋友有数据库设计规范的参考文献？
• 数据库设计
• 数据库设计
• 数据库设计问题
• 数据库设计问题
• 关于数据库设计?
• 数据库设计问题
• 关于数据库设计
• 应用数据库设计