Хранение больших изменяемых массивов на iPhone

Question

Хорошо, я не могу найти четкий ответ на этот вопрос хранения на iPhone.В моём модельном классе есть несколько иваров и два очень больших (МБ) изменяемых массива данных, которые собираются с внешнего устройства и затем анализируются.Я думаю, что у вас есть данные в объекте (похожие на заметку или музыкальный файл), и вы можете сохранить их в постоянном «файле» данных, а затем открыть старый файл данных и просмотреть их (нетредактирование старых данных будет сделано).Наряду с этим я хочу еще один сохраненный объект, который отслеживает несколько ключевых битов информации из каждого из файлов данных, а также имеет ссылки на них (возможно, пользователь может щелкнуть точку данных, и он откроет соответствующий файл данных -если он все еще существует (он может быть удален пользователем для экономии места)).

Я вижу множество советов, рекомендующих использовать все хранилища данных для приложений iPhone с использованием Core Data.Дело в том, что, кроме одностороннего «файла», между объектами нет взаимосвязей.Объекты могут рассматриваться как ноты или музыкальные файлы, они не заботятся о существовании друг друга, и существует только один существующий объект («загруженный») за один раз (либо в памяти с данными, добавляемыми к нему).и будет сохранен позже или загружен из просматриваемого хранилища).

Каков наилучший способ управлять этим?В настоящее время контроллер устройства (управляет связью устройства) создает модель и отправляет в нее данные (модель анализирует и анализирует данные).Но должен ли быть какой-то контроллер, который обрабатывает файлы (или управляемый объект Core Data, что угодно), который создает объект, сохраняет данные, освобождает память и затем загружает новый с сохраненными данными?

Любой советбыть полезным, поскольку лучшие примеры хранения, которые я нашел, кажутся очень реляционными (сотрудник, начальник, компания) - что, как я вижу, выиграет от базы данных.Но в то же время ручное хранение списка файлов в каталоге может потребовать больше усилий, чем какой-либо другой метод.

Answer 1

Я не могу найти цитату в документации Apple, но я прочитал (и мне сказали инженеры Apple), что «большие» объекты данных иногда лучше всего хранить вне Core Data. Предложенная модель помещает BLOB (большие двоичные объекты) в файловую систему с объектами Core Data, ссылающимися на эти большие объекты (т. Е. Хранит относительные или абсолютные пути к файлам).

Итак, если предположить, что ваши большие двоичные объекты являются музыкальными данными, то ваша модель базовых данных может иметь сущность, которая содержит метаданные (например, размер, время / продолжительность и т. Д.), А также ссылку на файл, который содержит фактические данные. данные. Ваша сущность метаданных также может иметь отношения с другими сущностями в вашей системе. Например, вы можете хранить спектрограммы для музыкальных данных и хранить их в отдельной сущности.

Я боролся с этой проблемой за данные, которые отбирались с различных измерительных датчиков. В конечном итоге я решил, что мои наборы данных были достаточно малы (в большинстве случаев) для хранения с Базовыми данными в качестве свойств NSData выделенного объекта. Объект обертки был «выделенным», чтобы избежать загрузки данных только для отображения метаданных пользователю.

Обновление

Я нашел строку о BLOB в Руководстве по программированию базовых данных в конце раздела «Большие объекты данных (BLOB)»:

Лучше, однако, если вы можете хранить BLOB как ресурсы на файловая система, и поддерживать ссылки (например, URL-адреса или пути) к тем Ресурсы. Затем вы можете загрузить BLOB как и при необходимости.

Answer 2

Если вам не нужен какой-либо доступ к базе данных (быстрые запросы, частые обновления и т. Д.), База данных требует слишком много накладных расходов, как с точки зрения кодирования, так и производительности.Функции базы данных не совсем бесплатны, поэтому я могу придумать множество сценариев, в которых вы получите лучшие результаты с меньшими усилиями, если выберете один из следующих вариантов:

• несколько файлов с отдельно сохраненным индексомfile;
• большой файл вашего собственного двоичного формата.

Выбор зависит от количества элементов, размера элементов, одинаковы ли их размеры, как часто вам нужноизменить данные и / или индекс и т. д.

Answer 3

Я бы также рекомендовал использовать Core Data. Хотя базовые данные позволяют легко обрабатывать отношения, никто не мешает вам использовать базовые данные для хранения несвязанной информации. Нет никаких правил против создания моделей в Базовых данных, которые не имеют никакого отношения друг к другу; просто не связывайте их вместе.

Базовые данные будут обрабатывать все операции чтения / записи в базу данных, что избавит вас от необходимости разбирать ваши собственные файлы. При первом использовании Core Data есть некоторая кривая обучения, но как только вы ее запустите, вы будете благодарны, что она есть.