SQLite vs Plist performance

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).

EDIT: Чтобы добавить немного информации: основные блоки представляют собой виды, которые должны быть загружены в этом порядке, а подблоки - это подпункты основных видов, которые должны быть в этом порядке. Некоторые данные - это данные, которые будут передаваться этим представлениям. Таким образом, порядок основных представлений и подпунктов будет время от времени изменяться, а данные для суб-представлений будут перезагружаться, когда пользователь решает. Надеюсь это немного поможет.

Answer 1

SQLite действительно предназначен для поиска через магазины записей, объединения данных и фильтрации данных, которые вам не нужны. Похоже, у вас есть структура данных, которая бы легко вписывалась в память (хотя вы должны измерить это, чтобы видеть только то, что у вас есть), требует небольшого редактирования. Это редактирование будет головной болью в SQLite, если вам нужно изменить схему таблицы. Почему бы просто не хранить его как структуру словаря/массива и использовать сериализацию для хранения в файле или даже по умолчанию для пользователя? Если вы намерены отобразить его в стандартных представлениях Apple, где вы хотите, чтобы одно представление сразу отображало изменения, сделанные в другом представлении, возможно, CoreData - ваш друг.

Answer 2

Это зависит. Если вы будете постоянно повторно ссылаться на структуру данных и будете каждый раз перезагружать plist, тогда SQLite DB (который вы оставите открытым) будет быстрее. Если вы загружаете и ссылаетесь только на данные, то plist выигрывает. И, конечно же, вы можете использовать Core Data для простых функций SQLite.