У меня есть модель данных, похожая на этот упрощенный рисунок:
альтернативный текст http://dl.dropbox.com/u/545670/thedatamodel.png
Это немного странно, но идея в том, что приложение управляет несколькими учетными записями / идентичностями, которые может иметь человек, в единую систему обмена сообщениями. Каждая учетная запись связана с одним пользователем в системе, и каждое сообщение потенциально может быть просмотрено / отправлено нескольким учетным записям (но они имеют глобально уникальный идентификатор, следовательно, свойство messageID, которое используется при импорте для извлечения объектов сообщений, которые, возможно, уже были загружено и импортировано предыдущей сессией).
Приложение используется с точки зрения каждой учетной записи - я имею в виду, что вы выбираете, какую учетную запись вы хотите использовать, а затем вы видите сообщения и прочее с точки зрения этой учетной записи в своем окне. Таким образом, у меня есть сообщения, прикрепленные к учетной записи, чтобы я мог легко получить сообщения, которые должны отображаться с использованием такой выборки:
fetch.fetchPredicate = [NSPredicate predicateWithFormat:@"%@ IN accounts", theAccount];
fetch.sortDescriptors = [NSArray arrayWithObject:[[NSSortDescriptor alloc] initWithKey:@"date" ascending:NO]];
fetch.fetchLimit = 20;
Похоже, это правильный способ настроить сообщения так, чтобы сообщения были разделены между учетными записями, и если сообщение помечено как прочитанное одним, я хочу, чтобы оно было прочитано другим, и т. Д.
В любом случае, после всех этих настроек большая проблема заключается в том, что использование памяти кажется немного сумасшедшим. Когда я настраиваю тестовый пример, в котором он импортирует сотни сообщений в систему и периодически повторно выбирает (используя упомянутую выше выборку) и показывает их в списке (в списке указаны только последние 20), память просто сходит с ума , 60 МБ .. 70 МБ ... 100 МБ ... и т. Д.
Я проследил это до связи «многие ко многим» между Учетной записью и Сообщением. Даже при включенной сборке мусора на управляемые объекты все еще сильно ссылается свойство отношения сообщений учетной записи. Я знаю это, потому что я помещаю журнал в завершение своего экземпляра Message и никогда не вижу его, но если я периодически сбрасываю контекст или выполняю refreshObject: mergeChanges: на объекте account, я вижу, что сообщения finalize и использование памяти остаются довольно согласованными ( хотя все еще несколько растет, но, учитывая, что я импортирую материал, этого следовало ожидать) Проблема в том, что я не могу все время сбрасывать контекст или объект учетной записи, потому что это действительно мешает наблюдателям, которые наблюдают другие атрибуты объекта учетной записи!
Возможно, я просто моделирую это неправильно или думаю о нем неправильно, но я продолжаю читать снова и снова, что важно думать о Базовых данных как о графе объектов, а не как о базе данных. Я думаю, что я сделал это здесь, но это, кажется, вызывает проблемы. Что мне делать?