设计大型数据库需要注意哪些地方

~
一个面试问题，关于数据库的设计。 面试开始那位仁兄直接的说了他所面临的问题，公司数据库数据到达百万级别，以后可能会到达千万，需要一个好的设计人员对数据库进行优化设计，这里指的是不光设计符合功能需求，更加要符合性能需求，就是说数据库设计上面需





一个面试问题，关于数据库的设计。


面试开始那位仁兄直接的说了他所面临的问题，公司数据库数据到达百万级别，以后可能会到达千万，需要一个好的设计人员对数据库进行优化设计，这里指的是不光设计符合功能需求，更加要符合性能需求，就是说数据库设计上面需要兼顾到效率。


他给我出了一道题目， 一个信息表，一个类别表。类别表中的类别成树形结构的，这个树可能会非常深，就是说类别会很多。信息表中有所有类别的信息。现在需要设计下类别表和信息表，使得信息表和类别表在查询的效率能够承受千万级别的数据。


我用比较正常的思维去设计，类别表中有id，name，parentid。这时候他说如果以这种方式设计那在查询的时候不断的用嵌套的方式查询效率不行，他让我想下，我说可以将类别表分为几个小表和信息表联结查询，他说这个方法不行。他就直接给我讲了他的方法，但是他说这个方法百万级可以，但是千万级的不行，他的方法也简单，设第一个大类为1，第一个大类下面的一个类别为2，那么在类别表中存储


id name category_id
1 第一大类下的一个小类 '1,2'

那么在查询的时候 select * from category where category_id like '1%';


只要like后面不要写'%1%'。 1的前面不要写%，在效率上面还是能够承受的，这个和索引类似。


他也指出虽然这种方法提高了一定效率但是每次有一个新类别加入时候总要再次遍历整个树形类别，在适合的位置插入，这样子的方式给维护类别表格带来一定麻烦。


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


命名的规范

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


游标（Cursor）的慎用

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


Declare Mycursor cursor for select count_no from COUNT
Open Mycursor
Fetch Mycursor into @vcount_no
While (@@sqlstatus=0)
Begin
If @vcount_no=’’ 条件1
操作1
If @vcount_no=’’ 条件2
操作2
??
Fetch Mycursor into @vcount_no
End
??
??
改为
Update COUNT set 操作1 for 条件1
Update COUNT set 操作2 for 条件2
??
??

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


Create #tmp /* 定义临时表 */
(字段1
字段2
??
)
Insert into #tmp select * from TOTAL where
条件 /* TOTAL中3万行 符合条件只有几十行 */
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 开始一个事务
COMMIT TRANSACTION 提交一个事务
ROLLBACK TRANSACTION 回滚一个事务

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


数据库性能调整

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


数据类型的选择

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


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


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


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


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


Select * from DATA_TAB1 where datepart(yy,DATE)=1998

分布式数据库需要考虑哪些问题?
答：在设计分布式数据库时，应特别考虑如下几个方面的问题：1. 数据保存 (存储分段/复制，横向/纵向表分区);2. 目录管理(catalog management): 命名，数据独立性3. 查询处理(基于代价的调优， 半合并)4. 数据更新(同步/异步)

数据库设计技巧
答：结果本来已经出了11月结果的账单发生了变化，导致财务实际的处理出现了问题。因此，数据的冗余有时候是有必要的，我们需要根据不同表的类型进行一些冗余的设计。对于数据库设计的考虑点还有很多，可能一时半会儿也说不完，大家如果有什么好的思路，也可以在下方评论或关注我给我留言。

数据库开发需注意哪些问题?
答：在数据库设计之前首先应该有明确的数据库设计规范，包括表，视图，字段等的命名规范,设计约束和存储过程等的编码规范。同时数据库设计应该遵守从逻辑设计到物理设计的实现思路，在充分了解客户需求的情况下，创建数据字典和ER模型，遵守数据库的设计范式等基本要求进行设计。

分布式系统,数据库设计方面,应注意哪些方面
答：但是结构是一致的）。响应速度快，一般用于大客户的解决方案缺点：用的硬件较多，开发成本较高（不像单台机器那样，不管如何都写到一台机器上）。集群：构建多个相同数据库（内容一样），类似备份(一个数据一生成一条数据，立马将该数据同步到另一台上面去，查询时可以多台任选一台，单台压力低)，一台...

MYSQL数据库设计数据类型选择需要注意哪些地方
答：•使用ENUM代替字符串类型，数据实际存储为整型。•字符串类型 •要尽可能地避免使用字符串来做标识符，因为它们占用了很多空间并且通常比整数类型要慢。特别注意不要在MYISAM表上使用字符串标识符。MYISAM默认情况下为字符串使用了压缩索引（Packed Index），这使查找更为缓慢。据测试，...

数据库设计:从概念到实施的6大关键步骤
答：数据库设计是一项复杂而细致的工作,它涵盖了从理解用户需求到实际运行的整个过程。以下是其核心的六个步骤,带你逐步深入了解。需求分析深入了解用户的需求是至关重要的。这包括理解他们需要什么样的数据、如何处理这些数据,以及他们对数据安全和完整性的期望。概念设计通过数据抽象,我们开始构建系统的概念模型。E...

学会如何应用数据库——数据库规范化技巧 (1)
答：使用正确的数据结构，可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称是“数据库规范化”。 本文简要介绍数据库规范化的基本概念和一些需要注意并力求避免的常见问题。 理解您的数据在设计表之前，应明确您打算如何处理数据，还要了解随着时间的推移数据会发生什么样...

数据库设计之旅:揭秘六大阶段
答：数据库设计是一个复杂而又重要的过程,它需要经过多个阶段的设计和优化,才能确保数据的精准无误和高效运行。本文将揭秘数据库设计的六大阶段,帮助读者更好地了解这个过程。需求分析阶段在这个阶段,我们需要挖掘用户需求,确保数据精准无误。这一步虽难且耗时,但为后续设计打下坚实基础。概念结构设计阶段在这个阶段...

数据库架构选型与落地,看这篇就够了
答：将订单作为主表,然后将其相关的业务表作为附表,取用户id然后 hash取模 ,分配到不同的数据表或者数据库上。 优点: 缺点: 讲到这里,我们已经知道数据库有哪些架构,解决的是哪些问题,因此, 我们在日常设计中需要根据数据的特点,数据的倾向性,数据的安全性等来选择不同的架构。 那么,我们应该如何选择数据库架构...

数据库窗体设计有哪些注意事项?
答：也就是说，可以在主窗体内包含子窗体，而子窗体内可以再有子窗体。主窗体与第一个子窗体间为一对多关系，而第一个子窗体与第二个子窗体间为一对多关系。例如，可以用一个主窗体来显示客户数据，用子窗体来显示客户的订单，再用另一个子窗体来显示订单的详细内容（参见罗斯文数据库的客户订单窗体，文件...