SQL 将每个单词分别存储在文档中的最有效方法答案

【问题标题】：SQL Most effective way to store every word in a document separatelySQL 将每个单词分别存储在文档中的最有效方法
【发布时间】：2013-12-23 00:53:54
【问题描述】：

这是我的情况（或请参阅底部的 TLDR）：我正在尝试创建一个系统，该系统将通过多个文档搜索用户输入的单词并返回包含这些单词的文档。用户将搜索数千个文档，每个文档将有 10 到 100 多页长，并存储在网络服务器上。

我现在的解决方案是将每个唯一单词存储在带有 ID 的表中（英语中可能只有 120 000 个相关单词），然后在单独的表中存储单词 id，它所在的文档，以及它在该文档中出现的次数。

例如：文档 foo 的文本是

abc abc def

文档栏的文字是

abc def ghi

Documents 表会有

id | 姓名

1 'foo'
2 'bar'

单词表：

id | 单词

1 'abc'
2 'def'
3 'ghi'

Word 文档表：

字号 | 文档编号 | 发生次数

1        1        2
1        2        1
2        1        1
2        2        1
3        2        1

正如您所见，当您拥有数千个文档并且每个文档都有数千个独特的单词时，Word 文档表会很快爆炸，并且搜索时间过长。

TL;DR 我的问题是：

如何将大型文档中的可搜索数据存储在 SQL 数据库中，同时保留基于自定义因素（如发生率、以及其他人）没有一个完整的大表来存储将每个单词链接到文档及其在该文档中的属性的所有条目？

抱歉阅读了很久，感谢您的帮助！

【问题讨论】：

【解决方案1】：

您是否考虑过使用 lucene 搜索 api 的 C# .net 实现，而不是使用 SQL Server 构建自己的搜索引擎？看看https://github.com/apache/lucene.net

【讨论】：

【解决方案2】：

好问题。我会捎带 SQL Server 的现有解决方案（全文索引）。他们集成了一个很好的索引引擎，它的优化比你自己的代码可能做的要好得多（或者微软的开发人员很懒，或者他们只是一角钱来构建它:-)

请参阅SQL server 文本索引背景。您可以查询 sys.fulltext_index_fragments 等视图或使用存储过程。

当然，捎带现有解决方案有一些缺点：

但是，如果您允许 SQL Server 进行索引，您可以更轻松地用更少的时间构建自己的解决方案。

【讨论】：

【解决方案3】：

你的问题让我觉得很幼稚。首先......你在乞求这个问题。您正在为自己的问题提供有缺陷的解决方案……然后解释为什么它不起作用。如果您简单地描述您的目标是什么，您的问题会好得多......然后让开，让比您更聪明的人可以告诉您如何实现该目标。

就在手边……对我来说，数据库听起来真是个愚蠢的主意。长期以来，人们一直在类 UNIX 环境中使用命令行工具查找文本。要么已经存在可以解决你的问题的东西，要么一个像样的 perl 脚本会为你“伪造”它——当然，这取决于你的现实世界的限制。

根据您的实际问题，我怀疑这可能会涉及到一些非常有趣的计算机科学问题——索引、贝叶斯过滤，还有谁知道呢。但是，我怀疑您正在使一项非常基本的任务变得比需要的复杂。

TL;DR 我的答案是这样的：

** 你为什么不写一个脚本来遍历一个目录...然后使用正则表达式来计算每个文件中单词的出现次数？

【讨论】：

所以你的意思是不需要预处理成千上万的文档来使后续搜索更快？解决方案是每次只搜索所有文件？即使系统需要快速进行大量搜索？
这可能是一个严重的问题，mbeckish。将文档分解为数据库中的单个单词的问题在于它不允许您搜索短语或模式。如果速度是个问题，您可以随时缓存搜索结果，以免重做最常用的搜索。
如果您存储每个单词的正确索引数据，您还可以搜索短语，正如其他人在上面提到的那样。
此解决方案将部署在网络服务器上。我最诚挚的道歉，我忘了在原帖中澄清这一点。成千上万的用户将同时访问数百万个文档。我无法想象快速搜索所需的那种硬服务器端存储。我提供有缺陷的解决方案的原因是为了帮助人们理解目标，以防我不够清楚。