CoreData или отдельные файлы (iOS)

Question

У меня есть небольшая загадка: лучше ли использовать прямое управление файлами или базу данных CoreData SQLite?

Вот мой сценарий:

У меня есть куча объектов 'user', каждый со списком объектов 'post'. Это легко сделать в CoreData, и было бы замечательно - однако объекты 'post' загружаются с веб-сервера, и каждый из них имеет уникальный идентификатор. Я не хочу иметь несколько «постовых» объектов с одним и тем же идентификатором. Я мог бы решить эту проблему путем кэширования ответов CoreData в NSDictionary, однако это не очень хорошо применимо к шаблону разработки приложения. Насколько я знаю, при добавлении нового 'сообщения' в мой CoreData NSManagedObjectContext мне пришлось бы искать уникальный идентификатор, чтобы проверить его существование (быстро), затем добавить его, если он не существует (медленно), и обновить предыдущий, если он делает (быстро). Это эффективно заменяет его. Как вы, ребята, справитесь с этим?

Я уже несколько дней пытаюсь придумать альтернативы, но как бы я ни смотрел на это, CoreData будет медленнее, чем моя альтернатива:

Файловая архитектура в каталоге Caches / приложения iOS может решить эту проблему. Примерно так:

• Пользователи /
  • {уникальный идентификатор} .user
  • {уникальный идентификатор} .user
• Сообщения /
  • {уникальный идентификатор} .post
  • {уникальный идентификатор} .post

Затем, при получении объекта post или user, я могу проверить файлы на наличие данных и кэшировать содержимое файла в NSDictionary. Если идентификатор существует в словаре, вместо этого получите его оттуда. Замена предыдущих объектов 'user' и 'post' так же проста, как перезапись файла и обновление кэша.

Моя вторая альтернатива явно была бы быстрее - однако я бы не стал использовать какие-либо преимущества, встроенные в CoreData, и мне пришлось бы предоставить собственную схему управления памятью для очистки моих кэшированных словарей при предупреждении о памяти.

Есть ли какой-нибудь способ «уникальности» в CoreData? Это решило бы мою проблему. Нечто похожее на использование первичного ключа в обычной базе данных SQLite.

Я начну проводить тесты для проверки скорости обоих методов, но я решил опубликовать это здесь, прежде чем начинать на случай, если у кого-нибудь найдутся лучшие решения.

Answer 1

Этот точный вопрос часто возникает.

Вы можете проверить, существует ли значение в Базовых данных, не считывая весь объект.Просто установите выборку для выборки конкретного свойства, которое вы хотите проверить, в этом случае идентификатор, а затем верните выборку в виде словаря.Предоставьте предикат, который ищет один или несколько идентификаторов, и если возвращаемый словарь имеет значения, вы знаете, что у вас есть объекты.

Очень редко вы можете получить пользовательскую систему, которая будет быстрее и надежнее, чем Core Data.Это редко стоит даже пытаться.

Помните также, что преждевременная оптимизация - корень всего зла.Вся эта работа основана на предпосылке, что простейшая реализация Core Data - медленная.Вы действительно проверили, что это медленно?Если нет, сделайте это, прежде чем пытаться более сложные проекты.

Answer 2

После тестирования я обнаружил, что CoreData, по крайней мере, вдвое сокращает время.Тест, который я выполнял, был следующим: я добавил 1000 сообщений в пустой граф объектов CoreData;а затем извлек 100 из этих объектов для обновления.Время, необходимое для добавления объектов, составляло 0,069 с, а время, необходимое для извлечения объектов, составляло 0,181 с.Я получил эти значения на устройстве 3G iPad.При использовании файлов добавление этих объектов занимало в 10 раз больше времени, а извлечение их - в 4 раза дольше.

Моя рекомендация: придерживайтесь CoreData!