sql server-全文搜索

Question

假設我有兩個數據庫，一個用於生產，另一個用於開發。

當我們復制開發數據庫時，全文目錄沒有被正確復制，因此我們決定自己創建目錄。 我們匹配了所有表和索引並創建了數據庫，搜索功能似乎也可以正常工作（但已經過全面測試）。

但是，以前的目錄在其文件夾中比我們手動創建的目錄包含更多的文件。 這樣好嗎 我以為它們的文件數完全相同（但大小可能會有所不同）

Answer 1

首先 ...使用全文本搜索時，我建議您不要手動嘗試創建向導為您執行的操作。 我想知道丟失的不僅僅是一些數據。 為什么不只是重新創建索引？

其次 ...我建議您不要使用sql server的自由文本功能，除非您別無選擇。 我曾經在自由文本大的信徒，但表現出創建一個Lucene（.NET）指數和比較搜索它創建SQL Server中的索引和搜索它的一個例子。 與創建Lucene索引相比，創建SQL Server索引要慢得多且難以維護。 與Lucene相比，搜索SQL Server索引的准確性（可憐的結果）要低得多。 Lucene就像擁有自己的個人Google來搜索數據一樣。

怎么樣？ 在Lucene中索引數據（僅需要搜索的數據），並包括要索引的數據的主鍵以供以后使用。 然后使用您的語言和Lucene（.net）API搜索索引（有關此主題的許多文章）。 在搜索結果中，請確保您返回PK。 確定了您感興趣的記錄后，便可以根據返回的PK獲取其余數據和/或任何相關數據。

陷阱？ 更新索引也更快，更容易。 但是，您必須自己滾動才能創建索引，更新索引和搜索索引。 超級容易做...但是仍然...這里沒有向導或一手編碼！ 此外，索引位於文件系統上。 如果該文件是開放的，被搜索並嘗試再次打開它的另一個搜索你顯然有一些問題......所以寫某種形式的開放周圍基礎設施和閱讀這些指標需要建立。

這對SQL Server有何幫助？ 您可以輕松地將Lucene搜索包裝到CLR函數或proc中，然后將其安裝在數據庫中，然后就可以將其用作t-SQL查詢的本機。