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

У меня есть дизайн базы данных, который достаточно хорошо нормализован, но теперь мне нужно добавить новую таблицу (сущность, поскольку я фактически использую Core Data), и я столкнулся с некоторыми проблемами.

Ландшафт имеет много Assessment
Assessment имеет один AssessmentType
AssessmentTree имеет одну Assessment
AssessmentTree имеет по одной из 12 других объектов, опущенных для пробела.

Теперь я добавляю объект Photo, который может быть связан с ЛЮБЫМ из вышеперечисленных объектов. Мне нужно иметь какое-то отношение, чтобы я мог получить только фотографии, связанные с AssessmentTree, например, или, возможно, оценку, которая будет надмножеством фотографий, связанных с AssessmentTree.

(Я чувствую, что, возможно, не очень хорошо объяснил ситуацию, поэтому дайте мне знать, если я смогу как-то прояснить ситуацию.)

Возможные решения, которые я рассмотрел, ни одно из которых не удовлетворяет:

  1. Создавайте ссылки на каждый другой объект внутри объекта Photo. В этом случае нулевые ссылки означают, что фотография не является частью этого набора.
  2. Создайте новую сущность PhotoRelations, которая будет содержать ссылку на фотографию и ссылку на один из прикрепленных к ней объектов. Проблема в том, что хотя я мог бы легко сделать это с помощью системы SQL, я не могу придумать, как перевести это в CoreData.

Любая помощь будет оценена по достоинству!


person Evan Cordell    schedule 06.08.2010    source источник


Ответы (3)


Способ, которым Core Data предназначен для решения этой проблемы, заключается в наследовании сущностей.

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

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

Это боль. Я продолжаю надеяться, что они преломят это ограничение.

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

person TechZen    schedule 09.08.2010
comment
Я реализовал это, и он делает в основном то, что мне нужно, но я хотел бы иметь возможность связать несколько фотографий для каждого объекта, что кажется сложным с этим методом. Предложения? - person Evan Cordell; 09.08.2010
comment
Измените отношение фото в родительском на ко-многим. Это позволит вам связать произвольное количество фотографий с каждым экземпляром субобъекта. - person TechZen; 09.08.2010

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

Однако что вы планируете хранить в Photo? Если это просто двоичные данные, я бы пересмотрел их и вместо этого сохранил путь к файлу на диске. Хранение двоичных данных в Core Data далеко не идеально. Затем, если вы перейдете к простому сохранению пути к файлу, вы сможете полностью пропустить объект и просто сохранить filePath в родительском объекте (объектах).

person Marcus S. Zarra    schedule 07.08.2010

Что вы можете сделать, так это создать таблицу отношений следующим образом:

связанный идентификатор | фотоидентификатор | Тип ссылки

LinkType может быть любым из перечисленных выше в виде целого числа 1-N.

person schoetbi    schedule 06.08.2010
comment
Это не отличается от моей второй идеи и требует добавления поля id к каждому другому объекту, а также кучи дополнительного кода для отслеживания указанных идентификаторов. - person Evan Cordell; 06.08.2010