数据库设计：表的设计命名的十个注意点

标签： 数据库 设计 设计 | 发表时间：2014-04-09 23:30 | 作者：yupengcc
出处：http://www.iteye.com

1．表名一般以【模块名称_具体表名】来实现，同一个模块的前缀是一样的。(Oracle大小写敏感，在ＳＱＬ中可以不用"_",因为可以用大小写一起的写法。这也是可以的)

2．表名称不应该取得太长（一般不超过三个英文单词，不推荐使用中文拼音，总的长度不要超过30个字符）。表名使用英文的原因，有些项目有英文版的需要，或者这个项目是给外国做的时候，使用英文是基本的要求，应该说这是一个习惯问题，多学一点英文也不是坏事
 
3．不使用tab或tb作为表前缀（本来就是一个表，为什么还要说明）。
 
4．一些作为多对多连接的表，可以使用两个表的前缀作为表名：如：用户登录表User_Login，用户分组表User_GroupInfo，这两个表建立多对多关系的表名为：User_Group_Relation（关系统一用Relation）。注意一点，主键在做其他表的外键时，或者在被其他表引用时，字段说明和字段名尽量保持一致，比如发帖表BBS_Topic里的用户字段写成UI_ID,这样跟用户信息表User_Info的主键UI_ID保持一致，看起来舒服，对应关系很明确，也不容易错，前后不一致时容易令人费解。
  
5．当系统中有一些少量的，重复出现的值时，使用字典表来节约存储空间和优化查询。如地区、系统中用户类型的代号等。这类值不会在程序的运行期变化，但是需要存储在数据库中。一般数据库中，都有一个数据字典表，用来保存系统所用到的基础数据，大型的字段表如省份城市区域的字典表，统一以Dictionary_作为前缀。
     
6． 与字段有关，默认的一些特殊字段， 很多表中，
　　比如一些业务处理表中，除了添加生成的自动编号ID（一般作为主键用），该记录创建的时间CreateDate(创建时间),该记录的创建人CreatBy（注意这里，没UI_ID（用户信息表User_Info的主键UI_ID）,因为还有修改人），最后修改人LastEditBy，最后修改时间LastEditDate。（这些可以直接使用中文字符，而不使用编码，提高查询的效率）
　　同时有的时候需要注意，删除的时候并不真的删除该记录，而是添加一个标识位，比如XX_DeleteStaus删除状态。1是有效的，0则是无效的。
 
7．在命名表时，用单数形式表示名称。例如，使用 Employee，而不是 Employees。
 
8．数据库中应建立这样一个表，就是数据库本身的字段信息，表的说明，也就是数据库设计文档的一个表，方便查询使用，有什么不明的可以直接从数据库查询，数据库文档丢失，注释丢失，都可以重新起作用。
 
9．每个表都应该有一个主键，这个主键最好是数字，而且是递增的，有很多表的主键用32位字符编码，这样做的目的更多的是从安全考虑的。因为字符多时索引时效率低，而使用自增列也不是很少，比如添加主表和从表操作时，主表的主键是从表的外键，这个时候还有取返回值，然后再添加，不可以同时添加。主键可以用自定义的规则，大部分用MAX（ID）的做法，也可以自定义一个序列表，有点像序列，或者用时间的年月日秒具体到毫秒。关于列的命名,建议对数据类型也做一些规范，因为很容易确定，只有四种主要类型：数字，字符，时间，逻辑值，这些在类型上和长度上都可以定好规范，统一起来。
     
10．操作日志表，登录日志表，这是数据库中必备的两个表，这个记录也需要做进一步的保存。这个有两种情形，一是具体到单个字段的操作日志，二是整个表的操作日志。

常见的几个表具体说明：操作日志表Sys_OperateLog、登录日志表Sys_LoginLog、

　　　　　　　　　　　系统字典表Sys_Dictionary、系统字典表类型Sys_DicType

 

操作日志表Sys_OperateLog
中文名 字段名 注释
操作日志编号 OL_ID 索引列，日志的编号
操作类型 OL_Type 是添加，修改，删除，查询等类容（可放在通用字典表）
操作模块 OL_Module 操作模块，比如新闻模块，关联的是菜单表编号
操作内容 OL_Content 操作了什么内容，越具体越好（修改前、修改后）
操作人 UI_ID 用户的信息
操作时间 OL_AddDate 日志记录创建时间
操作IP OL_IP 操作人的IP地址
备注信息 OL_Remarks 备注信息，一些其他的需要说明的信息

 这样的一个操作日志比较笼统，不是能具体到具体的字段值更新，如果要具体到某个具体值的更新，则需要设计新的数据库

一般情况下需要这样几个表，系统中可能已经有了，但是我们拿到我们自己的数据库中来，一个是数据库列表的表（就是数据库中有几个表）（编号，创建时间，创建人，修改时间，修改人，表名，注释，是否删除），然后就是数据库表下面的字段类型（编号，创建时间，创建人，修改时间，修改人，字段名，字段类型，字段精度，字段说明，字段注释，表的编号），也就是字段列表，这时的日志操作表可以这样设计(编号，表名，被修改的字段名，修改前值，修改后值，操作人，操作时间，相关模块，操作IP） 这种能记录修改记录，但是添加和删除时记录就不是很方便控制了。

 

登录日志表Sys_LoginLog
中文名 字段名 注释
登录日志编号 LL_ID 登录的日志编号
登录人 UI_ID 登录人
登录时间 LL_AddDate 登录时间
登录IP LL_IP 登录的IP地址
登录状态 LL_Status 登录是否成功的标识位
登录浏览器 LL_Browser 登录浏览器
登录分辨率 LL_Resolution 登录的屏幕分辨率

还有一个就是数据字典表，我看过很多的数据库设计，类型表一个接一个，没有放在一起，还有的干脆写在注释里，有的根本就没有，这样某个程序员走了，这个字段就没人知道了，即使没走，自己也有可能时间长了忘掉，所以，见一个基础数据字典表的作用非常重要，其他的比如地区表(Sys_DicArea)，汉语拼音表（Sys_DicCharacter）(用来汉字和拼音的转换)因为数据量较大，单独建表。这里介绍通用的数据字典表。

 

系统字典表Sys_Dictionary
中文名 字段名 注释
字典编号 SD_ID 字典的编号，可以直接使用此主键编码（注意删除时的关联关系）
字典类型 DY_ID 字典类型的ID，需要建立字典类型表，因为放的是所有的字典表
字典编码 SD_Code 字典编码，支持自己编码（同一类型是唯一的，一般是整数型
字典中文名称 SD_Name 字典中文名称（比如男女，比如状态，可以放在字典表里，作为查看依据）
字典备注 SD_Remarks 字典备注，字典需要一些备注信息
创建人    
创建日期    
修改人    
修改日期    

 

系统字典表类型Sys_DicType
中文名 字段名 注释
字典类型编号 DT_ID 字典的自动索引号
字典类型名称 DT_Name 字典类型的中文名称
字典的备注说明 DT_Remarks 字典使用的备注说明
字典状态 DT_Status 字典是否删除，不在使用

 

最后补充一些内容，一般设计数据库是这个样子的，但是不排除有些特殊的情形，为了数据的保密性，数据库的表名和字段名都是一些看似毫无意义的字符数字，比如Table1，Col1，但是有一个表是说明表，或者有对应的数据库文档设计。

 

补充：一些列说明了单位类型，可以在设计数据库的时候表明，比如HeightIncm, WeightInKg.这样一目了然。

 



已有 0 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐



相关 [数据库 设计 设计] 推荐：

数据库设计规范

- - SQL - 编程语言 - ITeye博客
数据库表的命名以是名词的复数形式且都为小写，如cities, categories, friends等等. 如果表名由几个单词组成，则单词间用下划线("_")分割，如subscribed_pois,poi_categories等. 表名尽量用全名，表名限制在30个字符内. 当表的全名超过30字符时，可用缩写来减少表名的长度，如description --> desc；information --> info；address --> addr等.

数据库设计的三大范式

- 文斌 - 博客园-首页原创精华区
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则. 在关系型数据库中这种规则就称为范式. 范式是符合某一种设计要求的总结. 要想设计一个结构合理的关系型数据库，必须满足一定的范式. 在实际开发中最为常见的设计范式有三个：. 如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式.

数据库设计注意事项

- - CSDN博客推荐文章
           数据库设计包括：库的设计，表的设计，字段的设计，主键和外键的设计，索引设计，约束设计. 1、数据库名称要明确，可以加前缀或后缀的方式，使其看起来有业务含义，比如数据库名称可以为Business_DB(业务数据库）. 2、在一个企业中，如果依赖很多产品，但是每个产品都使用同一套用户，那么应该将用户单独构建一个库，叫做企业用户中心.

数据库设计的最佳实践

- - CSDN博客数据库推荐文章
1、使用定义明确的表或列名，并保持一致（例如，School、StudentCourse、CourseID）. 2、使用单数形式的表名（即，用StudentCourse而非StudentCourses）. 表代表了实体的合集，不需要复数形式. 否则你将在定义表时不得不使用“{”、“[”等字符（即为了访问表Student Course，你须得书写“Student Course”.

SQLite数据库存储引擎设计

- - searchdatabase
　　SQLite是一个嵌入式库并且实现了零配置、无服务端和事务功能的SQL数据库引擎. 它在广泛领域内被使用，而且单线程读写性能与MySQL比肩，并且保证ACID性. 　　SQLite的存储后端是采用Btree实现，多个连接可以并发操作，但是同一时间只允许一个写着存在. 　　SQLite在硬盘上一个数据库一个文件，每个数据库文件头部保存有这个数据库的元信息，包括版本，大小，Btree根节点位置等等.

ORACLE数据库优化设计方案

- - CSDN博客推荐文章
本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案. 关键词 ORACLE数据库 环境调整 优化设计 方案. 对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级包括硬件平台, 第二级调整是ORACLE RDBMS级的调整,.

进销存数据库表设计

- - 数据库 - ITeye博客
CREATE TABLE user /*用户表*/ (. CREATE TABLE Supplier /*供应商表*/ (. NOT NULL, /* 供应商编号 ,主键 */. NOT NULL, /* 供应商名称 */. NOT NULL, /* 地址 */. CREATE TABLE Customer /* 客户表*/ (.

Typecho的数据库设计的学习

- - 标点符
Typecho是一款仿Wordpress，但相对Wordpress要简单的多的开源博客程序. 开发者大量的参考了WordPress的设计，去除了一些高级复杂的功能，实现了一个小而美的博客系统. 轻量高效：仅仅 7 张数据表，加上不足 400KB 的代码，就实现了完整的插件与模板机制. 超低的 CPU 和内存使用率，足以发挥主机的最高性能.

数据库优化：mysql数据库单机数十亿数据查询设计

- - Seay's blog 网络安全博客
    很久没写文章，是不是想着写点什么东西，分享下我的数据库设计思路，主要是针对单机数十亿及以上数据查询优化技巧. 如果只是简单的查询，没有频繁的写入操作，对查询速度不要求在毫秒级别，就不需要什么大型的数据库软件设计复杂的集群关系，也不需要分布式水平分割等太重的优化. 只需要用mysql在本机笔记本搭建一个普通的环境就行.

数据库设计Step by Step (11)——通用设计模式（系列完结篇）

- Pei - 博客园-首页原创精华区
引言：前文（数据库设计Step by Step (10)——范式化）我们详细讨论了关系数据库范式，始于第一范式止于BCNF范式. 至此我们完成了数据库的逻辑设计，如下图所示. 正如首篇博文数据库设计 Step by Step (1)——扬帆启航中介绍的，本系列博文关注通用于所有关系数据库的需求分析与逻辑设计部分.