这是我的情况（或请参阅底部的TLDR ）：我正在尝试创建一个系统，通过多个文档搜索用户输入的单词并返回包含这些单词的文档。用户将搜索数千个文档，每个文档的长度为10-100多页，并存储在网络服务器上。
我现在的解决方案是将每个唯一的单词存储在一个带有ID的表中（英语中只有120 000个相关单词），然后在一个单独的表中存储单词id，它所在的文档，以及它在该文件中出现的次数。
例如：文件foo的文字是
abc abc def
和文档栏的文本是
abc def ghi
文件表将有
id |的名称
1 'foo'
2 'bar'
单词表：
id |的字
1 'abc'
2 'def'
3 'ghi'
Word文档表：
字ID | doc id |的出现
1 1 2
1 2 1
2 1 1
2 2 1
3 2 1
正如您所看到的，当您拥有数千个文档并且每个文档都有数千个独特的单词时，Word文档表会非常快速地爆炸并且需要很长时间才能进行搜索。
TL; DR我的问题是：
如何在SQL数据库中存储来自大型文档的可搜索数据，同时保留使用我自己的搜索算法的能力（我知道SQL内置了.docs和pdf），基于自定义因素（如发生，没有一个完全庞大的表格，所有条目都将每个单词链接到文档及其在该文档中的属性？
很抱歉阅读不久，感谢您的帮助！
答案 0 :(得分：5)
您是否考虑过使用lucene搜索API的C＃.net实现，而不是使用SQL Server构建自己的搜索引擎？看看https://github.com/apache/lucene.net
答案 1 :(得分：2)
好问题。我会捎带现有的SQL Server解决方案（全文索引）。他们集成了一个很好的索引引擎，它比你自己的代码可能做的更好地优化（或者微软的开发人员很懒，或者他们只需要一分钱来构建它： - ）
请参阅SQL server文字索引背景。您可以查询sys.fulltext_index_fragments等视图或使用存储过程。
当然，现有解决方案的捎带有一些缺点：
但是如果你允许SQL Server进行索引编制，你可以更轻松，更少的时间构建自己的解决方案。
答案 2 :(得分：-3)
你的问题让我觉得天真。首先......你在乞求这个问题。你正在为自己的问题提供一个有缺陷的解决方案......然后解释为什么它不起作用。如果你只是简单地描述了你的目标是什么......那么你的问题就会好得多......然后让人们比你能够聪明地告诉你 HOW 来实现这个目标。
就在手边......数据库听起来像是一个非常愚蠢的想法。人们长期以来一直在UNIX类环境中使用命令行工具来使用文本。任何已经存在的东西都可以解决你的问题，否则一个体面的perl脚本会为你“伪造”它 - 当然，取决于你的真实世界限制。
根据你的问题究竟是什么，我怀疑这可能会进入一些非常有趣的计算机科学问题 - 索引，贝叶斯过滤，以及谁知道还有什么。但是，我怀疑你做的一项非常基本的任务比它需要的更复杂。
TL; DR我的答案是：
**为什么不编写脚本来浏览目录...然后使用正则表达式来计算在那里找到的每个文件中单词的出现次数？