大型数据库设计原则

一个好的数据库产品不等于就有一个好的应用系统 如果不能设计一个合理的数据库模型 不仅会增加客户端和服务器段程序的编程和维护的难度 而且将会影响系统实际运行的性能 一般来讲 在一个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

事务的：原子性、一致性、分离性、持久性原子性、一致性、分离性、持久性(1)原子性事务的原子性指的是，事务中包含的程序作为数据库的逻辑工作单位，它所做的对数据修改 *** 作要么全部执行，要么完全不执行

这种特性称为原子性

事务的原子性要求，如果把一个事务可看作是一个程序，它要么完整的被执行，要么完全不执行

就是说事务的 *** 纵序列或者完全应用到数据库或者完全不影响数据库

这种特性称为原子性

假如用户在一个事务内完成了对数据库的更新，这时所有的更新对外部世界必须是可见的，或者完全没有更新

前者称事务已提交，后者称事务撤消（或流产）

DBMS必须确保由成功提交的事务完成的所有 *** 纵在数据库内有完全的反映，而失败的事务对数据库完全没有影响

(2)一致性事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态

这种特性称为事务的一致性

假如数据库的状态满足所有的完整性约束，就说该数据库是一致的

一致性处理数据库中对所有语义约束的保护

假如数据库的状态满足所有的完整性约束，就说该数据库是一致的

例如，当数据库处于一致性状态S1时，对数据库执行一个事务，在事务执行期间假定数据库的状态是不一致的，当事务执行结束时，数据库处在一致性状态S2

(3)分离性分离性指并发的事务是相互隔离的

即一个事务内部的 *** 作及正在 *** 作的数据必须封锁起来，不被其它企图进行修改的事务看到

分离性是DBMS针对并发事务间的冲突提供的安全保证

DBMS可以通过加锁在并发执行的事务间提供不同级别的分离

假如并发交叉执行的事务没有任何控制， *** 纵相同的共享对象的多个并发事务的执行可能引起异常情况

DBMS可以在并发执行的事务间提供不同级别的分离

分离的级别和并发事务的吞吐量之间存在反比关系

较多事务的可分离性可能会带来较高的冲突和较多的事务流产

流产的事务要消耗资源，这些资源必须要重新被访问

因此，确保高分离级别的DBMS需要更多的开销

(4)持久性持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失

即一旦一个事务提交，DBMS保证它对数据库中数据的改变应该是永久性的，耐得住任何系统故障

持久性通过数据库备份和恢复来保证

持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失

即对已提交事务的更新能恢复

一旦一个事务被提交，DBMS必须保证提供适当的冗余，使其耐得住系统的故障

数据库事务(Database Transaction) ，事务是一系列作为一个逻辑单元来执行的 *** 作集合。它是数据库维护数据一致性的单位，它将数据库从一致状态转变为新的一致状态，指作为单个逻辑工作单元执行的一系列 *** 作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有 *** 作都成功完成，否则不会永久更新面向数据的资源。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

数据库(Database)是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库。

数据库的基本结构分三个层次，反映了观察数据库的三种不同角度。

⑴ 物理数据层。

它是数据库的最内层，是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令 *** 作处理的位串、字符和字组成。

⑵ 概念数据层。

它是数据库的中间一层，是数据库的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据库所有对象的逻辑关系，而不是它们的物理情况，是数据库管理员概念下的数据库。

⑶ 用户数据层。

它是用户所看到和使用的数据库，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。

参考资料

数据库百度百科[引用时间2018-4-18]

数据库事务百度百科[引用时间2018-4-18]

以上就是关于大型数据库设计原则全部的内容，包括:大型数据库设计原则、数据库事务四大特性是什么、“数据库中的事务”是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！