用於線性但大型數據庫的SQLite或核心數據？

Question

我有一個數據庫有很多條目，但只有一個字段。想想一個基本的名單，按照字母順序排列大約20萬個名字。 該應用程序的用戶將能夠搜索此列表並獲得他的請求上的自動填充。

對於這種方法，SQLite或CoreData會更好嗎？或者不需要，因爲它只是一個數據領域？

在此先感謝。

編輯：更多的信息：所有的項目都是靜態的，並不會在所有

Answer 1

我認爲使用SQLLite支持的FMDB可能是更好的解決方案爲了這。在覈心數據中，每一行都將由一個對象實例表示，而這個對象實例又會包含一個字符串......這是很多包裝和結果的間接方式。

然而，最好的想法是測試這個 - 因爲它是一個如此簡單的模型，將SQLLite數據庫和CoreData數據庫放在一起，然後用200k項目和每個時間搜索它們填充每個項目將是最好的選擇。這可能是因爲CoreData的更高級的緩存可能有助於像用戶輸入的漸進式搜索字符串那樣刪除字符。

不要忘記將行標記爲索引！這對兩種情況都有幫助。

Answer 2

SQLite的編輯和CoreData將幾乎執行相同的，因爲後端的商店之一可以（默認情況下爲） SQLite，所以基本上它是一樣的，如果你使用一個或另一個。核心數據的主要優點是框架的所有額外好處，如緩存結果，面向對象的方式與數據庫進行交互，等等...

Answer 3

也許比數據存儲的選擇更重要的是自動完成算法的選擇以及與如何構建數據存儲中的數據有關的決定。

您不希望算法的「踢入」導致用戶的擊鍵或至少其中一些擊鍵被吞噬。您是否曾經在Google中輸入過搜索字符串，發現您輸入的前幾個字符不在文本框中？

您可能希望延遲字符串匹配，直到至少輸入三個字符，並且/或者您可能希望以非規範化的方式存儲數據，這可能更適合自動完成。

例如，你的PK或關鍵可能是「替代」和這個分隔字符串可能是該鍵的值：

  altar,alter,alteration,altercation,alternate,alternation,alternator,although, 
      altimeter,altitude,alto,altogether,altruism,altruist 

，而不是各自的那些話佔據自己的行。