大廈自動提示

我建立一個自動提示。目前，目標應用程序是桌面應用程序，但想法是將其構建得如同強大，然後將其包含在網絡中。大廈自動提示

現在我在項目的開始：思數據庫（SQL Server 2008）

自動提示將是來自〜40.000.000行的表。

現在我的選擇是：全文檢索或建立一個表像我現在就形容：

我自動提示項目：

a b c 
1 2 3 
x y z

結果表：

a b c    a b c 
a b c    a c b 
a b c    b a c 
a b c    b c a 
a b c    c a b 
a b c    c b a

對於每個項目都是如此。

現在我的問題：

那些至極最好的時候，我希望儘量減少自動提示列表中選擇搜索的項目？還有其他更好的嗎？

謝謝！

迭戈

來源

2010-11-11 Diego

在我看來FULLTEXT會更好，即使你只需要精確匹配。

然而，即使你決定不使用FULLTEXT爲什麼你需要索引的所有排列？您可以按字母順序將它們編入索引(a, b, c)，並將它們作爲參數提供給查詢，然後按相同順序重新排列這些項目。

也就是說，你應該總是尋找C, D, O即使您的查詢表示O, C, D

來源

2010-11-11 14:42:18 Quassnoi

我索引的所有排列，因爲我不會找精確匹配，我想，以減少更多鈔票的所有查詢時間在每個搜索。因此，當用戶開始提示任何字詞時，我可以創建一個「％」字樣，就這些了。 – Diego 2010-11-11 14:45:22

@Diego：在這種情況下，你絕對應該使用'FULLTEXT'指數 – Quassnoi 2010-11-11 14:46:23

@Diego：即使你決定使用'B-Tree'索引，你不需要索引的所有排列。在你的情況下，索引「a，b，c'，」b，a「和」c，b「，這只是」3「記錄，而不是」6「。看到這篇文章：http://explainextended.com/2009/05/09/creating-indexes/ – Quassnoi 2010-11-11 14:48:34

所以...你要根據部分輸入到查詢表與4000萬點的記錄，匹配列的任何部分（或甚至是多列），可能來自許多用戶同時......並且我假設您期待次秒的響應時間。

你的數據庫服務器最好是一個真正的野獸。

我強烈建議您重新考慮您的計劃，或者至少限制用戶的選擇，例如將搜索限制在列的開頭，等等。
但是，如果您決定繼續此操作，則全文不在這個問題，除非在應用程序中包含某種有趣的等待光標以在自動查詢查詢運行時招待用戶。

來源

2010-11-11 19:46:08

是的，我期待亞秒響應時間。但是我保存的所有排列都完全避免了你說的話：「匹配列的任何部分（甚至是多列）」。不，只有一列，只是在開始（因爲排列）。 – Diego 2010-11-12 11:29:04

大廈自動提示

回答

相關問題