Relations
假设我们正在经营一个汽车修理的业务. 除了其他一些必要的事情, 我们还需要追踪一辆车的服务历史, 即在该辆车上所有的修整记录. 那么我们可能会创建包含以下一些列的 ServiceHistory 表:
VIN | Make | Model | Year | Color | Service Performed | Mechanic | Price | Date这样, 每次当车辆维修以后, 我们就在表中添加新的一行, 并写入该次服务我们做了一些什么事情, 是哪位维修工, 花费多少和服务时间等.
但是等一下, 我们都知道，对于同一辆车而言，所有车辆自身信息有关的列是不变的。 也就是说，如果把我的 Black 2014 Lexus RX 350 修整 10 次的话， 那么即使 Make, Model, Year 和 Color 这些信息并不会改变，每一次仍然重复记录了这些信息. 与无效的重复记录相比， 一个更合理的做法是对此类信息只存储一次， 并在有需要的时候进行查询。
那么该怎么做呢？ 我们可以创建第二张表： Vehicle , 它有如下一些列:
VIN | Make | Model | Year | Color
这样一来， 对于 ServiceHistory 表， 我们可以精简为如下一些列:
VIN | Service Performed | Mechanic | Price | Date你可能会问，为什么 VIN 会在两张表中同时出现？ 因为我们需要有一个方式来确认在 ServiceHistory 表的 这 辆车指的就是 Vehicle 表中的 那 辆车, 也就是需要确认两张表中的两条记录所表示的是同一辆车。 这样的话,我们仅需要为每辆车的自身信息存储一次即可. 每次当车辆过来维修的时候， 我们就在 ServiceHistory 表中创建新的一行， 而不必在 Vehicle 表中添加新的记录。 毕竟， 它们指的是同一辆车。
我们可以通过 SQL 查询语句来展开 Vehicle 与 ServiceHistory 两张表中包含的隐式关系:
SELECT Vehicle.Model, Vehicle.Year FROM Vehicle, ServiceHistory WHERE Vehicle.VIN = ServiceHistory.VIN AND ServiceHistory.Price > 75.00;该查询旨在查找维修费用大于 $75.00 的所有车辆的 Model 和 Year. 注意到我们是通过匹配 Vehicle 与 ServiceHistory 表中的 VIN 值来筛选满足条件的记录. 返回的将是两张表中符合条件的一些记录, 而 "Vehicle.Model" 与 "Vehicle.Year" , 表示我们只想要 Vehicle 表中的这两列.
如果我们的数据库没有 索引 (indexes) (正确的应该是 indices), 上面的查询就需要执行 表扫描 (table scan) 来定位匹配查询要求的行。 table scan 是按照顺序对表中的每一行进行依次检查， 而这通常会非常的慢。 实际上, table scan 实际上是所有查询中最慢的。
可以通过对列加索引来避免扫描表。 我们可以把索引看做一种数据结构， 它能够通过预排序让我们在被索引的列上快速地找到一个指定的值 (或指定范围内的一些值). 也就是说， 如果我们在 Price 列上有一个索引， 那么就不需要一行一行地对整个表进行扫描来判断其价格是否大于 75.00, 而是只需要使用包含在索引中的信息 “跳” 到第一个价格高于 75.00 的那一行， 并返回随后的每一行（由于索引是有序的， 因此这些行的价格至少是 75.00）。
当应对大量的数据时， 索引是提高查询速度不可或缺的一个工具。当然， 跟所有的事情一样，有得必有失， 使用索引会导致一些额外的消耗： 索引的数据结构会消耗内存，而这些内存本可用于数据库中存储数据。这就需要我们权衡其利弊，寻求一个折中的办法， 但是为经常查询的列加索引是 非常 常见的做法。
The Clear Box
得益于数据库能够检查一张表的 schema (描述了每列包含了什么类型的数据), 像索引这样的高级特性才能够实现， 并且能够基于数据做出一个合理的决策。 也就是说, 对于一个数据库而言， 一张表其实是一个 “黑盒” (或者说透明的盒子) 的反义词？
当我们谈到 NoSQL 数据库的时候要牢牢记住这一点。 当涉及 query 不同类型数据库引擎的能力时， 这也是其中非常重要的一部分。
Schemas
我们已经知道, 一张表的 schema , 描述了列的名字及其所包含数据的类型。它还包括了其他一些信息， 比如哪些列可以为空， 哪些列不允许有重复值， 以及其他对表中列的所有限制信息。 在任意时刻一张表只能有一个 schema, 并且 表中的所有行必须遵守 schema 的规定 。
这是一个非常重要的约束条件。 假设你有一张数据库的表， 里面有数以百万计的消费者信息。 你的销售团队想要添加额外的一些信息 （比如， 用户的年龄）, 以期提高他们邮件营销算法的准确度。 这就需要来 alter (更改) 现有的表 -- 添加新的一列。 我们还需要决定是否表中的每一行都要求该列必须有一个值。 通常情况下， 让一个列有值是十分有道理的， 但是这么做的话可能会需要一些我们无法轻易获得的信息（比如数据库中每个用户的年龄）。因此在这个层面上，也需要有些权衡之策。
此外，对一个大型数据库做一些改变通常并不是一件小事。为了以防出现错误，有一个回滚方案非常重要。但即使是如此，一旦当 schema 做出改变后，我们也并不总是能够撤销这些变动。 schema 的维护可能是 DBA 工作中最困难的部分之一。
Key/Value Stores
在 “NoSQL” 这个词存在前， 像 memcached 这样的 键/值 数据存储 (Key/Value Data Stores) 无须 table schema 也可提供数据存储的功能。 实际上， 在 K/V 存储时， 根本没有 "表 （table）" 的概念。 只有 键 (keys) 与 值 （values） . 如果键值存储听起来比较熟悉的话， 那可能是因为这个概念的构建原则与 Python 的 dict 与 set 相一致: 使用 hash table （哈希表） 来提供基于键的快速数据查询。 一个基于 Python 的最原始的 NoSQL 数据库, 简单来说就是一个大的字典 (dictionary) .
为了理解它的工作原理，亲自动手写一个吧！ 首先来看一下一些简单的设计想法：
- 一个 Python 的 dict 作为主要的数据存储
- 仅支持 string 类型作为键 (key)
- 支持存储 integer, string 和 list
- 一个使用 ASCLL string 的简单 TCP/IP 服务器用来传递消息
- 一些像 INCREMENT, DELETE , APPEND 和 STATS 这样的高级命令 (command)
有一个基于 ASCII 的 TCP/IP 接口的数据存储有一个好处， 那就是我们使用简单的 telnet 程序即可与服务器进行交互, 并不需要特殊的客户端 (尽管这是一个非常好的练习并且只需要 15 行代码即可完成)。
对于我们发送到服务器及其它的返回信息，我们需要一个 “有线格式”