Предотвращение объединения основных данных в единую таблицу

Есть ли способ сообщить Core Data не помещать все ваши сущности в одну таблицу, когда все они наследуются от базового объекта? Вот пример: у нас есть объект "Entity" , и у нас есть "Person" и "Product", которые наследуются от "Entity" . Основные данные создают таблицу ZENTITY с комбинированными полями для "Entity" , "Person" и "Product". Мы хотим, чтобы основные данные создавали две отдельные таблицы: одну для "Личность" и одну для "Продукт".

Возможно ли это? Ничто нигде в Интернете не говорит об этом...

4 ответа

Я выполнял измерения, а производительность CoreData полностью ухудшалась при использовании наследования на реальных (~ 50000 объектов, 20 + классов, каждая из которых имела ~ 5 отношений, большинство из них для многих). Я не использую CD для игрушечных приложений с 1000 объектами - это реальное огромное приложение и пессимизм производительности необоснованны. Хуже того, создание небольших объектов занимает много памяти ssd и памяти из-за этой глупой реализации.

Единственное реальное решение (i DO NEED inheritance) заключается в замене хранимого хранилища sqlite по умолчанию на ручную реализацию с использованием NSIncrementalStore от iOS 5 и выше. Тем не менее, запрос на выборку для перевода SQL и обновления модели действительно сложно реализовать.

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


В соответствии с подробной статьей Флориана Куглера решение заключается в использовании наследования в коде модели, но не в вашей схеме:

Иерархия сущностей по иерархии классов

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

Что происходит за кулисами, так это то, что Core Data хранит все объекты с тем же родительским объектом в одной таблице. Это быстро создает таблицы с большим количеством атрибутов, замедляющие производительность. Часто цель создания иерархии сущностей заключается исключительно в создании иерархию классов, чтобы мы могли поместить код, разделенный между несколькими объектов в базовый класс. Существует намного лучший способ достичь это хотя.

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

https://www.objc.io/issues/4-core-data/core-data-models-and-model-objects/


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

Я нашел хороший ответ из этого URL: https://www.objc.io/issues/4-core-data/core-data-models-and-model-objects/#entity-hierarchy-vs-class-hierarchy.

Чтобы избежать появления URL-адреса в будущем, я разместил здесь несколько важных материалов:

Например, у нас есть авторы и книги, которые унаследованы от BaseEntity. Мы должны создавать объекты как они должны быть, а не использовать наследование.

Entity hierarchy Class hierarchy
---------------- ---------------
 Authors Books BaseEntity
 | |
 Authors Books

Код должен выглядеть следующим образом:

@interface BaseEntity : NSManagedObject
 @property (nonatomic) int64_t identifier;
 @property (nonatomic, strong) NSDate *createdAt;
 @property (nonatomic, strong) NSDate *changedAt;
@end
@interface Author : BaseEntity
 // Author specific code...
@end
@interface Book : BaseEntity
 // Book specific code...
@end


Нигде в Интернете не говорится о это..

Это потому, что таблицы не имеют ничего общего с Core Data.

Основные данные - это не SQL. Объекты не являются таблицами. Объекты не являются строками. Столбцы не являются атрибутами. Core Data - это система управления графами объектов, которая может или не может сохраняться в графе объектов и может или не может использовать SQL далеко за кулисами для этого. Попытка думать о Core Data в терминах SQL приведет к тому, что вы полностью не понимаете основные данные и получите много горя и потеряете время.

В этом случае, если ваша SQL-обучаемая интуиция для оптимизации SQL приведет к тому, что вы потратите много времени. Если вы достигнете максимума в своем хранилище SQLite при разработке, вы неправильно используете Core Data. Это не просто оболочка объекта для SQL.

Было принято решение о создании всех объектов с тем же наследованием в одну и ту же таблицу SQL, когда Core Data использует хранилище SQLite. Однако в большинстве случаев это мало функциональной значимости, поскольку Core Data сначала управляет графом объектов и мало заботится о деталях сохранения. Если у вас есть большое количество объектов одного дерева наследования объектов, вы можете столкнуться с некоторой проблемой производительности на самом высоком конце, например. 20k +, но в противном случае нет.

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

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

licensed under cc by-sa 3.0 with attribution.