84. 从视图索引说Notes数据库（下）

作用和代价
上文介绍了关系型数据库里的索引。Notes数据库里的索引隐藏在视图概念里（本文的讨论只针对Notes的视图索引，不包含全文索引。）。开发人员创建的视图仅仅是存放在数据库里的一条设计文档，数据库引擎会依据它创建和更新索引。关系型数据库里的索引是从记录中抽取的数据排序而组成的数据结构（主要是B树），Notes视图的索引还包括未排序的列、计算值、分类、总计等等数据（数据结构仍然是B树，如果运气足够好的话，你会遇到Notes报出B-tree structure is invalid的错误）。用户在客户端里看到的视图就是索引的数据，再加上外观的设置。这样的区别缘于两类数据库底层设计的差异。
关系型数据库里的索引是为了查询而建的。SELECT NAME, JOB FROM PERSON WHERE COUNTRY='China'这样一个简单的查询语句，会因为PERSON表的COUNTRY列建有索引而大大提高速度。而对SELECT * FROM PERSON这样无选择的查询语句，是否有索引则没有区别。作为文档型数据库的Notes，情况略有不同。文档型数据库里作为存储数据单元的文档，与关系型数据库里对应的记录相比最大的差异就是，文档没有记录受到的所在表定义的约束，例如一条记录有多少列，列的名称和数据类型是什么，长度几何等等。每条文档都可以有任意数量、名称和数据类型的字段。如果说某个表里的每条记录都有一个共同的schema，那么可以说每条文档都有自己的schema。在有些文档型数据库里，如大热的MongoDB，文档还被归类在表示同一种实体的collection里，有类似table的含义和用途。而在Notes数据库和另一热门CouchDB里，连这样的容器都没有，所有的文档，无论内容和用途是什么，都直接处于