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

Question

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

Ландшафт имеет много оценок
У оценки есть один тип оценки
У дерева оценок есть одна оценка
В дереве оценки есть один из 12 других объектов, пропущенных для пробела.

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

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

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

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

Любая помощь будет принята с благодарностью!

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

связанный идентификатор | photoId | LinkType

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