动态搜索和显示

你所说的被称为 inverted index 或者张贴清单,并且操作类似于你的提议和麦基的提议。有很多关于倒排索引的文献;维基百科的文章是一个很好的开始。

更好的方法是使用现有的反向索引实现,而不是自己构建它。MySQL和PostgreSQL的最新版本默认都有全文索引。您也可以退房 Lucene 一个独立的解决方案。写一篇文章要考虑很多事情 好的 反向索引,包括标记化、词干化、多字查询等,预构建的解决方案将为您完成所有这些工作。

最快的方法当然是根本不使用数据库,因为如果使用优化的数据手动进行搜索,您可以轻松击败select搜索性能。假设文档不经常更改,最快的方法是建立索引文件并使用这些文件查找关键字。索引文件的创建方式如下:

1. 在文本文件中查找所有唯一的单词。它将文本文件按空格拆分为单词,并将每个单词添加到列表中,除非已在该列表中找到。

2. 把你找到的所有单词按字母顺序排列;最快的方法是使用 Three Way Radix QuickSort . 在对字符串进行排序时,该算法的性能很难击败。

3. 将排序后的列表写入磁盘,一行一个字。

4. 当您现在想搜索文档文件时,完全忽略它,而是将索引文件加载到内存中,并使用二进制搜索来确定索引文件中是否有单词。在搜索大型排序列表时,二进制搜索很难击败。

或者,可以在单个步骤中合并步骤(1)和步骤(2)。如果您使用insertionsort(它使用二进制搜索来找到正确的插入位置,将一个新元素插入到一个已经排序的列表中),那么您不仅有一个快速的算法来确定这个词是否已经在列表中,如果它不在列表中,您会立即得到正确的插入位置,如果您总是插入这样的新词,那么,yo当你进入步骤(3)时,你会自动得到一个排序列表。

问题是,每当文档更改时,都需要更新索引…但是,对于数据库解决方案来说,这不是真的吗?另一方面,数据库解决方案为您带来了一些优势:您可以使用它,即使文档包含如此多的单词,索引文件也无法再放入内存中(不太可能,因为即使是所有英文单词的列表也可以放入任何普通用户PC的内存中);但是,如果您需要加载大量文档的索引文件,则记忆可能会成为一个问题。好吧,你可以使用巧妙的技巧来解决这个问题(例如,使用mmap直接搜索映射到内存中的文件等),但是数据库已经使用了这些技巧来执行快速查找,因此为什么要重新发明轮子呢?此外,还可以防止文档更改时(即,如果数据库可以为您执行锁定,或者可以作为原子操作执行更新)在搜索单词和更新索引之间出现锁定问题。对于使用Ajax调用列表更新的Web解决方案,使用数据库可能是更好的解决方案(如果这是一个用C等低级语言编写的本地运行的应用程序,那么我的第一个解决方案相当合适)。

如果您想在一个选择调用中完成这一切(这可能不是最佳的,但是当您使用Ajax动态更新Web内容时,它通常被证明是导致最少头痛的解决方案),那么您需要将这三个表连接在一起。可能SQL有点生疏,但我会尝试一下:

SELECT COUNT(Document.idDoc) AS NumOfHits, Documents.Name AS Name, Documents.Location AS Location 
FROM Documents INNER JOIN Word_Docs ON Word_Docs.idDoc=Documents.idDoc 
INNER JOIN Words ON Words.idWord=Words_Docs.idWord
WHERE Words.Word IN ('Word1', 'Word2', 'Word3', ..., 'WordX')
GROUP BY Document.idDoc HAVING NumOfHits=X

好吧,也许这不是最快的选择…我想可以做得更快。无论如何,它将找到所有至少包含一个单词的匹配文档,然后按ID将所有相等的文档分组在一起,计算已分组到一起的文档数,最后只显示numofhits(在语句中找到的单词数)等于in语句中单词数的结果(如果搜索10个单词,则X是10)。

不确定语法(这是SQL Server语法),但:

-- N is the number of elements in the list

SELECT idDoc, COUNT(1)
FROM Word_Docs wd INNER JOIN Words w on w.idWord = wd.idWord
WHERE w.Word IN ('word1', ..., 'wordN')
GROUP BY wd.idDoc
HAVING COUNT(1) = N

也就是说,不用like。相似的事情要复杂得多。

Google Desktop Search 或者类似的工具可能满足您的需求。