数据库设计技巧

就我个人的经验来说，数据库虽然在设计上确实需要有一定的经验，但是它并不是最难的。

对于数据的设计其实是对于现实中业务的一种抽象。

就我的习惯的话，我会先对于现实中的业务场景、业务的角色进行分析。

就拿一般的进销存系统来举例吧。

我有一个对于物料管理的仓库，我需要对我的物料的进销存进行管理。

那么我们就需要分析，没有系统的时候，人与人之间的业务是怎么流转的，他们都是通过哪些表单来进行流转的，上下级之间的消息传递和反馈都是怎么进行的。

当知道了业务以后，我们的数据库无非就是对于现实中的业务的一种具现。

对于业务的设计完成以后，就是针对角色的了。

例如：业务的传递都是在业务人员之间的，我们已经整理表单的传递，那角色其实就已经在这些传递中存在了。

但是，业务的角色是业务的角色，我们还要包括财务的角色，那对于财务来说，他需要在哪些环节看到这些业务的单据？并且需要怎么处理？财务的处理结果又包括哪些？不同的处理结果对于下一步的 *** 作又有什么影响。

当我们把这一切的逻辑整理完成后，我们对于数据库的功能上就已经满足了。

接下来的就是抽象数据的分类了。

例如：我们需要对不同的表进行一个分类，我个人喜欢把表分成三种，一种是基础数据表，一种是过程表，一种是结果表。

怎么解释呢？

基础数据表：顾名思义，就是对于基础数据的维护，哪些可以成为基础数据呢？就是我们的业务发生的各个过程中，这些数据都是可以参与其中的，这就是基础数据。

例如：货物的信息，客户的信息。

过程表：就是仅仅在一个过程中使用的表，当这个过程结束了，这个表就没用了。

例如：订单表，付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程，关闭以后，这个订单表其实我们就不会再去使用它了。

结果表：这个表的数据有一个特点，只允许添加，不允许删除和修改，这个表的数据本身就是对于一种最终结果的表现。

例如：日志表、账单表。

那我们在进行数据库设计的时候，就需要将这些使用情况考虑进去，将不同功能的表进行分离，尽量降低耦合，让相互表的修改不会影响使用。

例如：收款单，我们需要收一笔款的时候，就会生成这个收款单，当款收到后，这个收款单的功能就结束了。

但现实的情况中，可能财务收到了这笔钱，结束了收款单流程后，他发现填错了，本来应该收100，结果收款单写的110。

但是，收款单表示的是过程，当这个过程结束了，我们就不会再需要上一个收款单了，所以，按照我们业务的处理流程，我们应该先生成一笔冲抵的收款单，例如收到-110，然后再生成新的100的收款单。

我们每个月还会有财务统计报表，财务报表因为和现实中的财务账有关，是绝对不允许变动的，因此，这个财务报表就是一个结果表，我们会按月通过批处理程序，将收款单的明细和统计数据放到另一张表中，感觉好像比较冗余，但是这个确实非常必要的。

因为我曾经就遇到过一个情况，我们直接用过程表来进行数据的统计，然后11月30日有一笔收款已经完成了，结果发现收错了，就重新做了个收款单，结果本来已经出了11月结果的账单发生了变化，导致财务实际的处理出现了问题。

因此，数据的冗余有时候是有必要的，我们需要根据不同表的类型进行一些冗余的设计。

对于数据库设计的考虑点还有很多，可能一时半会儿也说不完，大家如果有什么好的思路，也可以在下方评论或关注我给我留言。

数据库设计步骤

数据库设计可以分为概念结构设计、逻辑结构设计和物理结构设计三个阶段。

（1）概念结构设计。这是数据库设计的第一个阶段，在管理信息系统的分析阶段，已经得到了系统的数据流程图和数据字典，现在要结合数据规范化的理论，用一种数据模型将用户的数据需求明确地表示出来。

概念数据模型是面向问题的模型，反映了用户的现实工作环境，是与数据库的具体实现技术无关的。建立系统概念数据模型的过程叫做概念结构设计。

（2）逻辑结构设计。根据已经建立的概念数据模型，以及所采用的某个数据库管理系统软件的数据模型特性，按照一定的转换规则，把概念模型转换为这个数据库管理系统所能够接受的逻辑数据模型。不同的数据库管理系统提供了不同的逻辑数据模型，如层次模型、网状模型、关系模型等。

（3）物理结构设计。为一个确定的逻辑数据模型选择一个最适合应用要求的物理结构的过程，就叫做数据库的物理结构设计。数据库在物理设备上的存储结构和存取方法称为数据库的物理数据模型。

一：先抽象一个公用的“商品”实体，然后每一个具体的类型的商品继承这个实体，可是这样子设计的话，不同种类的商品一多的话，那么表就越多。感觉还是很糟糕。

二：直接在”商品“这个实体里添加多一个属性，属性的值按约定的规则（如键值对）来描述包括这个商品种类信息，这样子的话就只要一张表就行。不过这样子做的话，在展示商品信息需要在前台对这个属性值进行分离，感觉好像哪里不太符合规范。

一个好的数据库产品不等于就有一个好的应用系统 如果不能设计一个合理的数据库模型 不仅会增加客户端和服务器段程序的编程和维护的难度 而且将会影响系统实际运行的性能 一般来讲 在一个MIS系统分析 设计 测试和试运行阶段 因为数据量较小 设计人员和测试人员往往只注意到功能的实现 而很难注意到性能的薄弱之处 等到系统投入实际运行一段时间后 才发现系统的性能在降低 这时再来考虑提高系统性能则要花费更多的人力物力 而整个系统也不可避免的形成了一个打补丁工程 笔者依据多年来设计和使用数据库的经验 提出以下一些设计准则 供同仁们参考

命名的规范

不同的数据库产品对对象的命名有不同的要求 因此 数据库中的各种对象的命名 后台程序的代码编写应采用大小写敏感的形式 各种对象命名长度不要超过 个字符 这样便于应用系统适应不同的数据库

游标（Cursor）的慎用

游标提供了对特定集合中逐行扫描的手段 一般使用游标逐行遍历数据 根据取出的数据不同条件进行不同的 *** 作 尤其对多表和大表定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等特甚至死机 笔者在某市《住房公积金管理系统》进行日终帐户滚积数计息处理时 对一个 万个帐户的游标处理导致程序进入了一个无限期的等特（后经测算需 个小时才能完成）(硬件环境 Alpha/ Mram Sco Unix Sybase ) 后根据不同的条件改成用不同的UPDATE语句得以在二十分钟之内完成 示例如下

Declare Mycursor cursor for select  count_no from COUNT

Open Mycursor

Fetch Mycursor into @vcount_no

While (@@sqlstatus= )

Begin

If  @vcount_no=   条件

*** 作

If  @vcount_no=   条件

*** 作

Fetch Mycursor into @vcount_no

End

改为

Update COUNT set  *** 作 for 条件

Update COUNT set  *** 作 for 条件

在有些场合 有时也非得使用游标 此时也可考虑将符合条件的数据行转入临时表中 再对临时表定义游标进行 *** 作 可时性能得到明显提高 笔者在某地市〈电信收费系统〉数据库后台程序设计中 对一个表（ 万行中符合条件的 多行数据）进行游标 *** 作(硬件环境 PC服务器 PII Mram NT Ms Sqlserver ) 示例如下

Create #tmp   / 定义临时表 /

(字段

字段

)

Insert into #tmp select from TOTAL where

条件  / TOTAL中 万行 符合条件只有几十行 /

Declare Mycursor cursor for select from #tmp

/对临时表定义游标/

索引(Index)的使用原则

创建索引一般有以下两个目的 维护被索引列的唯一性和提供快速访问表中数据的策略 大型数据库有两种索引即簇索引和非簇索引 一个没有簇索引的表是按堆结构存储数据 所有的数据均添加在表的尾部 而建立了簇索引的表 其数据在物理上会按照簇索引键的顺序存储 一个表只允许有一个簇索引 因此 根据B树结构 可以理解添加任何一种索引均能提高按索引列查询的速度 但会降低插入 更新 删除 *** 作的性能 尤其是当填充因子（Fill Factor）较大时 所以对索引较多的表进行频繁的插入 更新 删除 *** 作 建表和索引时因设置较小的填充因子 以便在各数据页中留下较多的自由空间 减少页分割及重新组织的工作

数据的一致性和完整性

为了保证数据库的一致性和完整性 设计人员往往会设计过多的表间关联（Relation） 尽可能的降低数据的冗余 表间关联是一种强制性措施 建立后 对父表（Parent Table）和子表(Child Table)的插入 更新 删除 *** 作均要占用系统的开销 另外 最好不要用Identify 属性字段作为主键与子表关联 如果数据冗余低 数据的完整性容易得到保证 但增加了表间连接查询的 *** 作 为了提高系统的响应时间 合理的数据冗余也是必要的 使用规则（Rule）和约束（Check）来防止系统 *** 作人员误输入造成数据的错误是设计人员的另一种常用手段 但是 不必要的规则和约束也会占用系统的不必要开销 需要注意的是 约束对数据的有效性验证要比规则快 所有这些 设计人员在设计阶段应根据系统 *** 作的类型 频度加以均衡考虑

事务的陷阱

事务是在一次性完成的一组 *** 作 虽然这些 *** 作是单个的 *** 作 SQL Server能够保证这组 *** 作要么全部都完成 要么一点都不做 正是大型数据库的这一特性 使得数据的完整性得到了极大的保证

众所周知 SQL Server为每个独立的SQL语句都提供了隐含的事务控制 使得每个DML的数据 *** 作得以完整提交或回滚 但是SQL Server还提供了显式事务控制语句

BEGIN TRANSACTION 开始一个事务

MIT TRANSACTION 提交一个事务

ROLLBACK TRANSACTION 回滚一个事务

事务可以嵌套 可以通过全局变量@@trancount检索到连接的事务处理嵌套层次 需要加以特别注意并且极容易使编程人员犯错误的是 每个显示或隐含的事物开始都使得该变量加 每个事务的提交使该变量减 每个事务的回滚都会使得该变量置 而只有当该变量为 时的事务提交（最后一个提交语句时） 这时才把物理数据写入磁盘

数据库性能调整

在计算机硬件配置和网络设计确定的情况下 影响到应用系统性能的因素不外乎为数据库性能和客户端程序设计 而大多数数据库设计员采用两步法进行数据库设计 首先进行逻辑设计 而后进行物理设计 数据库逻辑设计去除了所有冗余数据 提高了数据吞吐速度 保证了数据的完整性 清楚地表达数据元素之间的关系 而对于多表之间的关联查询（尤其是大数据表）时 其性能将会降低 同时也提高了客 户端程序的编程难度 因此 物理设计需折衷考虑 根据业务规则 确定对关联表的数据量大小 数据项的访问频度 对此类数据表频繁的关联查询应适当提高数据冗余设计

数据类型的选择

数据类型的合理选择对于数据库的性能和 *** 作具有很大的影响 有关这方面的书籍也有不少的阐述 这里主要介绍几点经验

Identify字段不要作为表的主键与其它表关联 这将会影响到该表的数据迁移

Text 和Image字段属指针型数据 主要用来存放二进制大型对象（BLOB） 这类数据的 *** 作相比其它数据类型较慢 因此要避开使用

日期型字段的优点是有众多的日期函数支持 因此 在日期的大小比较 加减 *** 作上非常简单 但是 在按照日期作为条件的查询 *** 作也要用函数 相比其它数据类型速度上就慢许多 因为用函数作为查询的条件时 服务器无法用先进的性能策略来优化查询而只能进行表扫描遍历每行

例如 要从DATA_TAB 中（其中有一个名为DATE的日期字段）查询 年的所有记录

lishixinzhi/Article/program/Oracle/201311/17929

当前数据库可以根据业务需求来设计，一般会根据模块分成不同的表，每一个表都会有一些必要的字段来存储业务数据。

历史数据库可以将当前数据库的表结构复制出历史数据库，并且添加一个历史时间字段，在读取历史数据时可以根据历史时间来实现查询，以及增加一些特殊的历史数据统计字段来存储历史数据统计。

以上就是关于数据库设计技巧全部的内容，包括:数据库设计技巧、数据库设计步骤分为几个阶段、一件商品不同分类数据库设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！