Нарушение связи CoreData при извлечении основной сущности

У меня есть сущность с рядом отношений "ко-многим". Я представляю определенные свойства сущности в tableview, используя NSFetchedResultsController. Из всех отношений, которые имеет сущность, отображаются значения только 1 из отношений (в настоящее время они сброшены в cellforrowat... метод). Мне кажется, что это может повлиять на производительность. Можно ли в момент создания запроса на выборку нарушить определенную связь, чтобы CoreData не имела чтобы получить значения, когда таблица прокручивается?

3 2
cocoa-touch iphone

3 ответа:

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

NSArray *propertiesToFetch = [[NSArray alloc] initWithObjects:@"title", @"thumbnailImage", nil];
[fetchRequest setPropertiesToFetch:propertiesToFetch];
[propertiesToFetch release];

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

2

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

Тем не менее, я полагаю, что -[NSFetchRequest setRelationshipKeyPathsForPrefetching:] добьетесь того, чего хотите.

2

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

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

В общем, я бы сказал, Не пытайтесь перехитрить основные данные. На данный момент в нем есть годы оптимизации производительности. Хотя интуитивно может показаться, что для обнаружения ошибок в 100 объектах потребуется 100 запросов к базе данных, это не обязательно так.

1