用于线性但大型数据库的SQLite或Core Data?

时间:2011-08-30 14:33:15

标签: iphone database sqlite core-data

我有一个包含许多条目但只有一个字段的数据库。想想一个基本列表,大约有20万个名字按字母顺序排列。 该应用的用户将能够搜索此列表并获得他的请求的自动填充。

对于这种方法,SQLite或CoreData会表现得更好吗?或者不需要,因为它只是一个数据领域?

提前致谢。

编辑:更多信息:所有条目都是静态的,根本不会被编辑

3 个答案:

答案 0 :(得分:0)

SQLite和CoreData几乎可以执行相同的操作,因为其中一个后端存储可以(并且默认情况下)是SQLite,所以如果你使用其中一个,基本上它是相同的。 Core Data的主要优点是框架的所有附加好处,如缓存结果,面向对象的方式与数据库交互等等......

答案 1 :(得分:0)

我认为使用SQLLite支持的FMDB可能是更好的解决方案。在Core Data中,每一行都将由一个对象实例表示,而该对象实例又会包含一个字符串......这就是结果的大量包装和间接。

然而,最好的想法是测试这个 - 因为它是一个如此简单的模型,将SQLLite数据库和CoreData数据库放在一起,然后用200k项填充每个项目并对它们进行定时搜索将是最好的选择。可能是CoreData的更高级缓存可能有助于像用户输入的渐进式搜索字符串那样删除字符。

不要忘记将该行标记为已编入索引!无论哪种情况,这都会有所帮助。

答案 2 :(得分:0)

或许,比数据存储的选择更重要的是自动完成算法的选择以及与如何在数据存储中构建数据相关的决策。

你不希望算法的“踢进来”导致用户的击键,或者至少其中一些击中。您是否曾在Google中输入搜索字符串,但却发现您键入的前几个字符不在文本框中?

您可能希望延迟字符串匹配,直到至少输入三个字符和/或您可能希望以非规范化方式存储数据,这可能更适合自动完成。

例如,您的PK或密钥可能是“alt”,此分隔字符串可能是该密钥的值:

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

而不是让每个单词都占据自己的行。