理论和实践之理论

我们选择数据库的第一步是要清楚我们到底需要什么？数据库经过几十年的发展，有着繁多的种类，我们需要降低选择的数量。

最好的方法是按数据库的一些特点来归类，这里相关的术语包括"network（网络）"、 "relational（关系）"、 "object-oriented（面向对象）" 和 "embedded（嵌入）"，还有些派生的如"object-relational（对象关联）" 和 "embedded network（嵌入式网络）"。理解这些术语是重要的，因为不同类的数据库都是按照这种划分来工作的。

所有的数据库系统，不管它们术语如何划分，但它们都有一些共性。比如：它们都存储数据（这种超级废话也敢出来？）。这里我们先来理出它们的共性，然后在区分不同类数据库的差异。

数据的存取和管理
基本上，所有的数据库都提供这两种服务

首先是数据存取，我们大家熟悉的四员大将：添加新数据、查找数据、修改数据、删除数据。所有数据库都提供这些服务（不提供这种服务的数据库想必根本无法出生）。它们在不同类中可能工作的方式不同，这取决于数据库支持的记录结构。

数据库里的每个记录都是一条有价值的信息。例如，游戏里面的用户记录一般包括名字、职业、等级、攻击力、防御力、体力之类的无聊东东。记录通常被保存在表中。每个表装载着相同种类的记录。但常常，来自程序的应用要求我们在不同的结构中取得数据库记录，因此，对记录的操作意味着：
使用数据库不仅是搜索和修改记录，同时还要根据需求，通过编程的手段来获取需要的数据库记录。

再来就是数据管理，这玩意儿错综复杂，良好的数据管理是建立数据库重要组成部分。当你选择一个数据库来做应用时，必须确定你所选择的数据库的数据管理对你的应用的支持。

数据管理服务包括允许多个用户同时工作（并发），允许多个记录在瞬间被改变（事务处理），处理应用和系统崩溃（恢复）。不同的数据库系统提供不同的数据管理服务。数据管理完全不依赖前面所说的数据存取。

并发表示多个用户可以同时对数据库操作，它支持的范围从不开放（只允许单个用户）到全开放（所有用户读和写同时进行）

这里我们用玩家之间的道具交易来说明什么叫事务处理。玩家A现在要卖一把屠龙刀给玩家B，玩家B就要同时支付500金币给玩家A。现在就产生了一个问题，如果A把屠龙刀交给B的时候，系统突然发现B没有500金币，那么操作失败，A损失了一把刀。如果反过来，B给了500金币，系统突然发现A没有屠龙刀，那么B损失了500金币。但游戏中，我们采用了种种可以用人脑想得出来的无赖方法，收到钱就断线，拿到刀就砍死B，大多数因为速度慢而未得逞，但也有小部分确实造成了交易发生时中断，那为什么结果还是A拿着屠龙刀，而B揣着500金币呢。这一切都要归功于我们的事务处理：
在商务应用中，经常需要访问数据库，以完成对数据的查询、插入、更新、删除等操作。受应用逻辑的影响，有时需要将多条数据库操作指令组成一个工作单元(事务)。在数据库中，所谓事务是指一组逻辑操作单元，它使数据从一种状态变换到另一种状态。为确保数据库中数据的一致性，应当用离散的成组的逻辑单元操作数据：当它全部完成时，数据的一致性可以保持；而当单元中的一部分操作失败时，整个事务会被全部忽略，所有从起始点以后的操作全部退回到开始状态。（总之就是告诉你，有了事务处理就甭想有歪主意）

最后要讲的这玩意儿叫恢复。严格的讲，恢复从系统开始运行的时候就进行的一个程序。它的目的是保证数据库完整和可用。当数据库被损坏，这在系统或应用发生错误时比较常见。有许多数据管理服务允许数据的复制。比如，大多数数据库都允许导入导出。此外，一般都提供了一些方法支持数据库在发生损坏情况下的恢复。

在清楚了数据存取和数据管理服务之后，那你应该了解需要哪种数据库了吧。Berkeley DB是一套拥有丰富的数据管理服务，同时又支持相当简单的数据存取的嵌入式数据库。它的优点和弱点都是明显的，下一章我们把它同其他数据库做个比较。