"News Overview" 顾名思义, overview 就是先大略看看 article 的相关资讯。

举例而言, 假设一个 user 用 Netscape 的 News reader, 连上某个 News server 後, ( 当然用其它的 news reader, 情况也是类似的 )

这些 Subjects, From, Dates 等资讯, 基本上是藏在 News articles 里面. 一个 News reader 要得到这些, 就只好向 News server 要.

以往, News articles 数目不多时, 某一个 client 向 news server 要这 些 index 资料时, news server 自己到 spool directory 去 scan, open news articles, 将这些东西找出来, 丢给 client.

现在 newsgroups/news articles 数量多了, 还是用这样的方法, 系统自然 就很可能忙不过来. 所以, 现在改成建 NOV ( News OverView database), 从 News server 收到某一篇文章的同时, 就把这些 threading 需要的东西, 挑出来, 放到 NOV database 中. ( 通常是一个 newsgroups, 一个档 )

这样一来, 某一个 client 来要某一个 newsgroups 的 indexing 资料, news server 就把对应的 ".overview" file 打开, 将资料读出来, 送回给 news client. 不需要像从前一样, 到该 newsgroups 对应的 目录中, 将所有的 articles 都 open 一次.

而且, 因为是 articles 一进到系统时, ".overview" file 就被 updated, 这样对 system loading 的 impact 比较小, 不像有些系统 , 必须另外 透过 cron, 定时再去 scan spool, 再造出 indexing 资料, ...

还有, 需要强调的是, NOV (".overview") database 最好和一般的 articles 分开, 分别不同的 directory。

在配置文件 inn.conf 中的 ovmethod 指定 overview 的方式。

目前 overview 有三种：tradindexed，buffindexed，以及 ovdb。tradindexed 是读取快速，但是由于对每个新的 article 都要更新两个文件因此写入非常慢。buffindexed 使用了一的大缓冲区来存储所有的 overvew，因此在大量喂送（large feed）的时候非常胜任，但是对于使用者而言会觉得有点慢。ovdb 将 overview 的数据除存储在 Berkeley DB version 3 的 数据库中，不但快速而且非常健壮（robust），只是要多花点空间来存储而已。要注意的是没有像其他两个 Mechanism 经过了常时间的考验，因此是有风险存在的。

文章过期，NOV 会自动更新。但是如果文章被 cancel，NOV不会被更新。这样当文章过期后，文章在 spool 中不存在，而 NOV 中仍存在。这就需要用如下命令定期清理（可以把该命令加入到 crontab 中）：

$ expireover -s

重建 overview 数据库，使用 makehistory 命令（参见：makehistory 命令参考）：

$ makehistory -O -F -b -I -x