SQLite与Plist性能

Question

我有一些数据必须存储在我的应用程序本地，我想知道什么是存储它的最佳方式（从性能角度看）。没有太多数据，也没有什么。从plist的角度来看，数据看起来像这样：

 -root
    -main_block1
        -sub_block1
            -some_data
            -some_data
            -some_data

        -sub_block2
            -some_data
            -some_data
            -some_data

        -sub_block3
        -sub_block4
        ...
        -sub_blockn
    -main_block2
    -main_block3
    ...
    -main_blockn

将会有大约3-10个（我猜最多13-15个）主要区块。将主块视为一个字典，标题大约有10个字符。在每个主要块中，将存在1-10个（最多10个）子块，这些子块也是字典。每个子块将包含一些纯文本数据。字符串不超过100个字符（或者可能是200-300）。

我需要读取这些数据并将其混合一点（交换一个或两个主要块并交换一个或两个子块）。

我需要它尽可能快，因为我已经在我的应用程序中有相当多的东西，所以我想知道我应该使用什么？属性列表文件或SQLite数据库？
SQLite数据库基本上是一个文本文件，周围有一个代码包装器来操作它的内容所以我的猜测是在我的情况下plist文件会更快......

所述数据不会超过几十千字节（希望不会：P）。

编辑： 要添加一些信息：主要块是需要按此顺序加载的视图，而子块是主视图上需要按此顺序加载的子视图。一些数据是将被提供给这些视图的数据。因此，主视图和子视图的顺序将不时更改，并且当用户决定时，将重新加载子视图的数据。希望这有点帮助。

Answer 1

这取决于。如果您不断重新引用数据结构，并且每次都会重新加载plist，那么SQLite DB（您保持打开状态）会更快。如果您只加载并引用数据一次，则plist获胜。当然，您可以将Core Data用于简单的SQLite函数。

Answer 2

SQLite实际上是用于搜索记录存储，将数据连接在一起以及过滤掉您不需要的数据。听起来你有一个很容易适合内存的数据结构（尽管你应该测量它以查看你的内容），只需要很少的编辑。如果您必须更改表的架构，那么编辑将成为SQLite的头疼。为什么不将它保留为字典/数组结构，并使用序列化将其存储在文件中，甚至是用户默认值？如果您打算在Apple的标准视图中显示它，您希望一个视图立即显示在另一个视图中所做的更改，那么CoreData可能是您的朋友。