0

我们正在将应用程序的数据库迁移到 Windows Azure SQL 数据库。在应用程序中，有几个轻量级搜索功能，我们目前使用 T-SQL 和全文索引来处理搜索。但是，全文索引目前在 Azure 中不可用。

我正在研究诸如 Lucene.Net 之类的非 SQL 解决方案，它看起来很棒，但我认为这对于我们正在尝试做的事情来说可能有点矫枉过正。我们正在搜索的数据集并不庞大——平均不到 100,000 条记录——而且只有少数几个。一个示例表可能看起来像这样......

CREATE TABLE dbo.Items(
    [ItemID] [int] IDENTITY(1,1) NOT NULL,
    [Author] [varchar](255) NULL,
    [Subject] [varchar](255) NULL,
    [ItemContent] [nvarchar](max) NULL, 
CONSTRAINT [PK_Items] PRIMARY KEY CLUSTERED ([ItemID] ASC)
)

...我们要在其中搜索 Author、Subject 和 ItemContent 字段。Author 和 Subject 可以是多个单词，ItemContent 字段可以是几个段落，所以我看不出如何避免 Table Scan。全文索引表现得非常好，我并不期待这样做：

SELECT ItemID FROM dbo.Items WHERE Author LIKE '%' + @SearchTerm + '%' OR Subject LIKE '%' + @SearchTerm + '%' OR ItemContent LIKE '%' + @SearchTerm + '%'

有人对不使用全文索引优化此类搜索的方法有建议吗？

4

1 回答 1

0

另一种方法是创建（如果不是完整的数据仓库解决方案），也许是一些非规范化的表，将这些列组合成一条记录（或更少的记录）......所以你会有一个只有 ItemId|CombinedSearchableInfo 的数据库表，你的CombinedSearchableInfo 可能是“Herman Melville Moby Dick”，在这种情况下，您所做的计算工作更少（并且您可以使用不同的查询优化技术来处理类似的事情）。您只需要使用离线过程维护您的搜索表......

请记住，尽管 Lucene 可以提供拼写错误和相关性等方面的帮助，并且对于书籍和作者等领域空间，拼写错误是好的并且可能......

（此外，如果你走的是天蓝色的路线，你现在可以使用表存储和 blob 存储来做很多事情......你实际上可以运行你的带有全文索引的 sql 服务器作为你的 blob 存储的一部分，而不必改造任何东西......你会失去 azure sql 的所有性能优势，但是嘿......这是一个选项）

于 2012-07-18T02:21:38.397 回答