83. 从视图索引说Notes数据库（上）

索引是数据库系统重要的feature，不管是传统的关系型数据库还是时兴的NoSQL数据库，它攸关查询性能，因而在设计数据库时须要细加考量。然而，Lotus Notes隐藏技术底层。以用户界面为导向。追求高速开发的理念，使得“索引”鲜有开发者提及，甚至了解。大家仅仅论及视图。而当不同的人在不同的场合说“视图”时。所指各异。

普通用户假设用视图一词，指的是显示一行行信息的列表；开发者口里的视图。是数据库里的一类设计元素。这种设计元素，依照Lotus Notes的风格，将视图层的设计与数据层的定义混合在一起，前者比如列的字体、颜色、宽度；后者包括选择文档，提取字段和计算列内容，定义排序、分类、总计等等。假设单纯考虑Notes的数据库部分。后者的数据定义才是有关主题的。

Notes应用程序往往在使用了一段时间后，也就是在数据库变大，用户变多后，变得非常慢。当中一个重要因素就是视图，打开应用程序、新建改动文档、运行代理都可能或明或暗地打开视图。

这些时候。正是索引隐藏在视图背后影响着性能。

在主流开发所用的技术组合中，数据库是独立的一块。开发者需用与编写业务逻辑时所用的语言不同的专业知识来设计和定义数据，所以才会衍生出专精于此的数据库管理员。在Lotus Notes应用程序中，数据库、业务逻辑和用户界面的开发紧密耦合，在大公司里尽管也有人专职维护server，部署和更新数据库，可是他们一般不会检查数据库的设计来优化性能。数据库的性能是程序开发者的分内之事，而实际上，若非经验丰富的程序猿，应用程序慢到非常多用户无法忍受，性能在Notes程序猿开发时，差点儿不会被考虑。数据库慢仅仅会被归咎于文档太多、附件太大、Notes数据库本来就如此。

很多老程序猿开发的应用程序里。同一类文档仅仅是为了分类顺序的不同就建了十来个视图，每一个视图十多二十个列，六七列为分类，其他差点儿全设置了排序。

文档数量一旦增多，如此设计将严重影响性能，而在设计者眼里，仅仅是为了方便用户而且是Notes便利性的证明。这种视图设计和其功能滥用。当然责任不全在程序猿身上，引导他们这样做的Notes的开发理念、帮助文档都难辞其咎。

说了这么长的开场白，如今就来讨论索引及其和应用程序性能的关系。

先概括关系型数据库里的索引的作用，以作为Notes视图索引的对比。简单地说。索引就是在大量数据中为了高速查询建立的从数据中某些实用的信息到这些信息所在位置的映射。

字典前面的拼音和部首检字表就是索引。更形象的样例是国外非常多图书的末尾都附有的索引，能够此查到重要的词语出现的页码。数据库里的记录数量庞大。实际使用时又有找出符合各种各样条件的记录的需求。比如一个记录了一百万条人员信息的表。包括姓名、生日、性别、地址、电话号码等等信息。

要从中找出姓赵的或者电话号码是26538941的人。假设没有特别的帮助，数据库系统仅仅能逐行检查记录是否符合条件，找到一条记录平均所需读取和检查记录的数量是N/2（N为记录的总数）。假设从记录中提取电话号码字段，排序。而且每条号码指向相应记录在表中的位置，就建成了一个索引。此时再要查询电话号码是26538941的人，仅仅需对索引应用二分查询算法，工作量就会降低到log2(N)的级别，再加上从定位的索引行确定和读取原始数据行的一次操作。另外，由于索引的每一行数据比原始记录的每一条要短非常多。单次读取本身也更快。索引的负面影响则是空间和维护成本。

索引的数据本身要占领空间，这非常好理解。原始记录更新（新增、改动和删除）时。索引自然也要随着更新。索引的更新能够选择与原始记录同一时候、定时或者在用到索引也就是查询时再进行。但不管怎样，与没有索引相比。都须要额外的计算。新增记录时，更新索引单纯是性能上的开销。

改动和删除时，除非是对全部记录，否则都有选择条件。此时的索引正起到与查询时相同的帮助，而改动和删除后更新索引则是开销。由于前者的优点更大。所以合起来的效果一般对性能还是正面的（除非记录数量不大或者索引数量过多）。

在《从视图索引说Notes数据库（下）》里将接着具体讨论Notes视图索引。