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

Question

Я новичок в среде CoreData и пытаюсь понять, как она работает. В моем проекте у меня есть суперкласс VetExam, чьи подклассы Examination, Treatments и Vaccination, которые имеют те же атрибуты своего суперкласса и имеют ссылку на класс Pet. С другой стороны, класс Pet содержит массив ссылок каждого класса, кроме VetExam, который должен использоваться только для полиморфизма (чтобы я мог использовать объект VetExam и создать отдельное представление для каждого типа).

Основываясь на этой модели, я пытался создать сущности в CoreData, но, похоже, я должен указать для каждого типа обратную связь для каждой сущности. Это представляет проблему, поскольку со стороны объекта VetExam отношение имеет тип Pet, но на стороне Pet значение To-Many для каждого типа экзамена, что не позволяет мне получить обратную ссылку VetExam.

Поскольку это объяснение легко понять неправильно, я покажу вам его визуальное представление.

Проблема в VetExam сущности, чей атрибут Inverse не известен. Кто-нибудь знает, как бороться с этим типом ситуации?

Answer 1

Предварительная записка о наследовании ...

Класс наследования

И

Наследование объекта

Во-вторых, я выделю примечание в документации Apple:

Будьте осторожны с наследованием сущностей при работе с постоянными хранилищами SQLite. Все сущности, которые наследуются от другой сущности, существуют в одной и той же таблице в SQLite. Этот фактор в структуре постоянного хранилища SQLite может создать проблему производительности.

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

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

Итак, чтобы ответить на ваш вопрос ...

Мои логики c:

У каждого питомца может быть много экземпляров VetExam в течение его жизни, но каждый экземпляр VetExam выполняется только на одном питомце?

Если да, то создайте один -отношение многих между Pet и VetExam -

 Pet <—>> VetExam.

Все, что происходит во время VetExam, является любой комбинацией одного обследования, лечения и / или вакцинации. То есть и в попытке прояснить ситуацию, VetExam может по желанию пройти обследование, но может не пройти лечение или вакцинацию. Вероятно, это изменится для каждого VetExam, поэтому это напрямую связано с VetExam, а не с Pet.

Если да, то создайте необязательные отношения один к одному между VetExam и объектами Examination, Treatment and Vaccination .

 VetExam <—> Examination
 VetExam <—> Treatment
 VetExam <—> Vaccination

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

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