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

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

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

例如：文件foo的文本是

abc def

文档栏的文本是

abc def ghi

文件表将具有

id|名称

1 'foo'
2 'bar'

字数表：

id|word

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

Word文档表：

单词id|文档id|出现次数

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

正如您所看到的，当您有数千个文档，并且每个文档都有数千个唯一的单词时，Word文档表会迅速膨胀，并且搜索时间过长

TL；博士，我的问题是：

如何将大型文档中的可搜索数据存储在SQL数据库中，同时根据自定义因素（如事件发生率和其他因素）保留使用自己的搜索算法的能力（我知道SQL为.docs和PDF内置了一个搜索算法）没有一个完全庞大的表，包含所有链接每个单词到文档的条目以及文档中的属性

---

抱歉读了这么久，谢谢你的帮助

我觉得你的问题太天真了。首先。。。你在乞求这个问题。你给自己的问题提供了一个有缺陷的解决方案。。。然后解释为什么它不能工作。如果你简单地描述一下你的目标是什么，你的问题会好得多。。。然后让路，让比你聪明的人告诉你如何实现这个目标

马上。。。对我来说，数据库听起来真是个愚蠢的主意。很长一段时间以来，人们一直在类UNIX环境中使用命令行工具对文本进行灰显。要么已经存在可以解决问题的东西，要么一个像样的perl脚本会为您“伪造”它——当然，这取决于您的现实世界约束

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

TL；博士，我的答案是：

---

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

好问题。我将借助现有的SQL Server解决方案（全文索引）。他们集成了一个很好的索引引擎，它的优化效果可能比您自己的代码要好得多（或者微软的开发人员很懒，或者他们只是花了一毛钱来构建它：-）

请参阅文本索引背景。您可以查询诸如sys.fulltext\u index\u片段之类的视图，也可以使用存储过程

当然，依靠现有解决方案有一些缺点：

您需要拥有解决方案的许可证

当您的需求无法再得到满足时，您必须自己对其进行编程

---

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

与使用SQL Server构建自己的搜索引擎相比，您是否考虑过使用lucene搜索api的C#net实现？看看

如果全文搜索不能解决您的所有问题，那么关系数据库可能不是您想要的解决方案……内容索引人员实际上存储文档中每个单词的位置（这样您就可以判断单词是否彼此相邻、查找短语等），不仅仅是出现的次数。这是一个更适合于

nosql

的问题。我认为您的结构是正确的。这将是关于索引的问题，你研究过了吗？你是说没有必要对成千上万的文档进行预处理以加快后续搜索？解决方案是每次只搜索所有文件？即使系统需要快速进行大量搜索，这可能是一个严重的问题，姆贝基什。在数据库中将文档分解为单个单词的问题在于，它不允许您搜索短语或模式。如果速度是一个问题，您可以始终缓存搜索结果，以便不重做最常用的搜索。如果您存储每个单词的正确索引数据，您还可以搜索短语，以及上面提到的其他短语。此解决方案将部署在Web服务器上。我诚挚的道歉，我忘了在原来的帖子中澄清这一点。成千上万的用户将同时访问数以百万计的文档。我无法想象快速搜索需要什么样的硬服务器端存储。我之所以提供有缺陷的解决方案是为了在我不够清楚的情况下帮助人们理解目标。看起来我最好的选择是使用Lucene。谢谢