Базовая производительность данных с одним родительским объектом

Question

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

Сегодня я понял, что Core Data хранит все объекты, которые являются суб-сущностями Foo, в таблице с именем ZFOO.Я беспокоюсь о производительности Core Data, если кто-то с массивными наборами данных захочет его использовать, поскольку ВСЕ дочерние объекты класса foo будут храниться в одной огромной таблице ZFOO.

Любые мнения или рекомендации будут высоко оценены.

Answer 1

Я работал с @deathbob над этим проектом в качестве лидера iOS. В нашем случае у меня было несколько классов, которые содержали атрибуты "remote_id" и "remote_update". Я изначально настроил таблицы, используя подклассы. У меня была абстрактная сущность «RemoteEntity», которая содержала эти атрибуты и кучу других сущностей, унаследованных от нее, каждая со своими собственными. Я думал , что в итоге у нас будет множество таблиц, каждая из которых имеет remote_id, remote_update, а затем их пользовательские атрибуты. Вместо этого мы получили огромную таблицу, которую вы описываете.

Исправление было довольно простым: вы должны не настроить наследование через графический интерфейс. Вместо этого включите все атрибуты для этого объекта, включая ваши общие, в Core Data Modeller (это означает, что «remote_id» и «remote_update» будут появляться в каждой сущности. При этом мы можем использовать подкласс. После генерации классов ваших моделей создайте класс родительского объекта. Это должно , а не быть в GUI. Он должен наследоваться от NSManagedObject, а в файле .m свойства должны использовать @dynamic вместо @synthesize. Теперь, когда у вас есть родительский класс, он время настроить дочерние классы. Установите родительский класс на RemoteEntity (в моем примере) вместо NSManagedObject. Затем удалите все свойства, которые появляются в вашем суперклассе (в моем примере, "remote_id" и "remote_update").

Вот пример моего суперкласса https://gist.github.com/1121689.

Надеюсь, это поможет, подсказка @deathbob за указание на это.

Answer 2

В прошлом году я работал над проектом, который делал то же самое, мы хранили все в основных данных и все в основных данных, унаследованных от одного класса, который имел некоторые общие атрибуты.

У нас было где-то между 1k - 10k записей в основных данных, и производительность снизилась до такой степени, что мы переписали ее и удалили общего предка. Насколько я помню, простой поиск занимал несколько секунд, и вставки / обновления тоже были довольно дерьмовыми. Только после того, как дела стали мучительно медленными, мы взломали базу данных и заметили, что под данными обложек все данные хранятся в одной таблице.

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

Итак, с такой долей соли, как это было на старых iOS и старом оборудовании, я бы определенно не делал этого.

Answer 3

Задним числом это прекрасная вещь.

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

Базовые данные - это мощный зверь, но вы должны научиться контролировать зверя, и благодаря пионерам, которые ответили ранее, и улучшениям, которые Apple внесла в среду, сделать это сегодня намного проще, чем было пару лет назад (в частности iOS 5).

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

Помимо этого, существует ряд механизмов для управления размером набора данных, который вы выбираете. Это не было лучше объяснено для меня, чем в книге «Прагматическая книжная полка» - «Основные данные, 2-е издание, Хранение данных и управление для iOS, OS X и iCloud» (январь 2013 г.) Маркуса С. Зарра, и в частности Глава 4 под названием «Настройка производительности».

Прочтите это.