2013-07-17 4 views
1

Я использую основные данные в своем приложении для хранения объектов, которые могут иметь до 50 тыс. Объектов или более. У меня это сопряжено с NSFetchedResultsController в виде таблицы. Вид таблицы отлично работает из-за повторного использования ячеек, однако моя самая большая проблема заключается в том, чтобы охарактеризовать фактическую базу данных для получения набора данных.Как эффективно работать с большими наборами данных в Core Data?

Когда я впервые загружаю представление таблицы, мне нужны все результаты из db. Я использую запрос выборки по умолчанию с одним дескриптором сортировки, и я установил пакетный размер в 1000. На iPad 2 этот запрос занимает 15 секунд, чтобы закончить! Я также должен запустить этот запрос после того, как поиск был отменен, поэтому он делает приложение непригодным. Мое предположение заключается в том, что CD по-прежнему должен разрешать все эти результаты или настраивать разделы или что-то в этом роде, я действительно понятия не имею, но просто использование batchSize не помогает? Содержимое также очень динамично в том смысле, что новые строки всегда добавляются, изменяются порядок сортировки и т. Д., Поэтому кеширование имеет ограниченную выгоду.

Теперь я думаю, что лучшим вариантом было бы использовать fetchLimit в fetchRequest, а затем реализовать некоторый базовый пейджинг. Когда представление таблицы прокручивается до конца, введите следующую «страницу» результатов? Моя единственная проблема с этим подходом заключается в том, что я теряю sectionIndex, и я не думаю об этом.

У кого-нибудь есть идеи или проблемы с этим вопросом?

+0

Зачем вам нужен весь набор данных? – Wain

ответ

2

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

+0

thx Я понимаю, как работает размер партии, но моя проблема - это реальный SQL-запрос, который берет навсегда. –

+0

Но зачем вам нужна такая большая просьба? – Wain

+0

Хороший вопрос. К сожалению, именно так разработан продукт. Я предполагаю, что это не похоже ни на одно другое приложение, которое имеет большое количество строк, но оборачивается этим, только показывая x количество результатов на страницу. Единственный способ подражать этому - использовать fetchLimit, чтобы остановить Core Data от получения большего количества данных, чем это необходимо. Данные также не поддаются согласованной группировке, которую я мог бы использовать для сужения набора результатов. –

0

s.newave,

ли ваши строки имеют переменную высоту? Если это так, то в представлении таблицы вам будет предложено рассчитать каждую высоту и вызвать каждую строку. 15 секунд не является необоснованным временем для извлечения 50 тыс. Предметов.

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

Andrew

P.S. Контроллер выбранных результатов предназначен для основных приложений. представление таблицы 50K не является основным приложением. Если вы настаиваете на том, чтобы придерживаться дизайна стола 50K, вам придется создать свой собственный контроллер.

Смежные вопросы