CoreData: работа с полиморфными ассоциациями?

Question

Я не уверен, что здесь используется правильный термин, но, скажем, в моей модели есть четыре объекта: Person, Place, Tag и Photo.Любой из трех других объектов может иметь Photo, связанный с ним.Иногда Person сделает фотографию и прикрепит ее к Tag, или Place, или даже другому Person.Каков наилучший способ приблизиться к полиморфным ассоциациям в CoreData?

Answer 1

Я не рекомендую наследование сущностей для чего-то такого простого.Для этого дизайна у вас есть три отношения, каждое из Person, Place и Tag имеет отношение к Photo. Photo` имеет три обратных отношения.Это не должно быть более сложным, чем это.

Наследование сущностей - это очень тонкий инструмент, который может легко вызвать у вас много проблем.Любые объекты, которые наследуются от другого, будут сведены в одну таблицу.Если, как предположил @morningstar, вы создали сущность Noun и имеете наследование от нее Person, Place и Tag, в файле SQLite будет таблица ONE с индексами, указывающими на себя идругая злобность.

Когда использовать наследование сущностей?

Это довольно сложный вопрос, на который можно ответить простым правилом.Тем не менее, я бы сказал, что базовым показателем было бы убедиться, что итоговая таблица заполнена как минимум на 70%.Например, если у вас есть реферат с 6 атрибутами и двумя дочерними элементами с 2 атрибутами, то, вероятно, это будет примерно 80% -ная степень заполнения и, возможно, все в порядке.

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

Answer 2

Согласен с @mzarra.Если у вас Person, Place и Tag есть отношение к Photo, управлять им будет намного проще, и вы избежите проблем с индексацией плоских таблиц.Используйте другой шаблон проектирования, чтобы абстрагировать общее поведение между Person, Place и Tag.Со стороны хранилища у вас останется дополнительное неиспользуемое пространство на Photo для обратных связей, которые вы не используете, но это уравновешивает потраченное впустую хранилище, которое у вас будет на наследовании сущностей, сохраняя класс для каждой записи в таблице.

Answer 3

Другим способом решения этой проблемы является создание подклассов фотографии, каждый из которых имеет свой собственный набор отношений. Итак, вы бы создали PersonPhoto, PlacePhoto и TagPhoto. Каждый из этих объектов будет иметь соответствующие отношения с Person, Place и Tag соответственно. Все общие функциональные возможности и атрибуты будут жить в Photo, но подклассы сохраняют разделенные отношения.

Это, вероятно, эквивалентно созданию всех этих отношений на Фото, но я думаю, что это немного чище.

Answer 4

Использовать наследование сущностей. Создайте родительский объект Person, Place и Tag. В этом случае родительская сущность довольно глупа. У него нет атрибутов. Он не представляет четкую категорию объектов. Называть это «Существительное» - лучшее, что я могу придумать.

Имеет множество фотографий отношений, чтобы напечатать Фото. Фотография имеет обратную зависимость isPhotoOf с типом Существительное.