我正在尝试确定如何最好地设计存储设施以快速搜索文本。
每个客户每个文件可能有100,000条记录。
我正在处理这些文件并根据客户端配置指定的列生成表。
您选择哪种类型的数据库架构，无论是SQL，平面文件还是任何其他技术。
搜索会有很多行，我不知道最好的方法是什么。
创建一个名为SearchColumns的表
Id
CustomerId
DisplayValue
创建一个名为“SearchRecords”的表
Id
SearchColumnId
SearchText
在这种情况下，SearchRecords表将变得非常大，非常快，并且因为SearchText将是varchar（200），所以LIKE查询将会非常慢。
我还考虑过SearchRecords表上的全文搜索，但在测试样本表时，我没有得到我期望的结果。
我还考虑过每个客户的单独数据库 这将有助于短期内的表格大小，但在数月或数年后，表格大小和速度将会变慢。
如何制作一个可以搜索数百万条记录的快速可搜索表呢？
编辑：有关我正在存储的数据的信息：
我从xml文件中提取FullName，Address和Account Numbers等值。这些字段非常小，很可能永远不会超过200个字符。
答案 0 :(得分：1)
我不确定我理解这个问题。您是否选择了记录存储模式，并且需要知道如何最好地获取其中的内容，或者您是否还需要存储模式？您是否计划将XML解析为nText列，或者只是将XML文件，标记和所有内容加载到nText列中？
一般来说，如果您正在寻找性能，请在宽而浅的桌子上找一张窄而深的桌子。窄表通常需要较少的索引来加速搜索最常见的列，并且这些索引允许引擎将搜索分解为可并行化的块。大多数发动机也足够聪明，可以将“廉价”的过滤条件优先于“昂贵”; LIKE子句（如果存在）几乎肯定会在复合WHERE子句中最后执行，因此如果您可以提供任何其他信息来缩小搜索范围，尤其是在索引列上，则可以加快查询的一般性能。
您可能会考虑（我不敢相信我要推荐这个）主要元素数据的键 - 问题 - 答案模式（每个元素的开始和结束标记之间）。对于任何甚至部分模式定义都是标准化的情况，传统的静态定义表将更容易在几乎所有计数中使用，但如果您甚至不知道数据的结构，那么它在XML中，这种方法需要在特定文件的元数据和通用字段表之间进行某种映射，在这种情况下，key-question-answer将两者结合起来以获得更好的查询性能。
您拥有的唯一标识特定记录的信息（和/或您需要快速搜索以便廉价地缩小结果集的数据）将成为您的关键，元素名称是您的问题，价值就是您的答案。这将支持非常灵活的数据命名标准。由于数据是XML，因此相关数据可以存储为元素的属性（开始标记的一部分），您可能需要类似但更简单的表来搜索标记的可搜索属性数据，或者您可以将属性数据规范化为主表基于一些着名的混搭。拥有这些非常窄的每列行数也允许您非常轻松地将未搜索的列移动到“归档”表中;您可能仍需要保留数据，以防他们想要开始搜索列，但如果您当前不搜索列，则可以将其从表中执行繁重的操作，这将是大大减少查询时间。
如果您正在寻找CLOB字段的近似值，您根本不会打败LIKE查询。是的，对于非常大的文本值，它会很慢;帮助这一点的唯一方法是以不会导致错误的不匹配的方式拆分该文本（LIKE不会在拆分边界找到匹配），我认为你不会找到一个通用的这样做的方法;你必须知道你存储的内容，例如它在段落中，并且匹配永远不会跨越段落边界。
当所有的事情都说完了，我想你会发现，无论数据大小如何，大多数SQL RDBMS在给定足够的处理器强度时，几乎可以在任何智能模式上运行。搜索索引本质上是对数的而不是线性的，因此一个好的索引模式将有助于引擎显着地分解搜索空间。