Сокращение количества связей в базовых данных - PullRequest
0 голосов
/ 17 ноября 2018

Мое приложение поставляется с обширной моделью данных, созданной в Core Data. По мере роста модели я нахожу, что создаю множество необязательных отношений, и это выглядит более запутанным и раздутым, чем мне кажется. Есть ли правильный способ уменьшить количество отношений?

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

enter image description here

Однако, ясно, что число отношений легко выходит из-под контроля, если вы хотите вырастить эту модель . Кроме того, ничто не мешает текущему животному ошибочно получить более одной указанной сущности свойства. Я подумываю о переходе на альтернативу, где я удаляю взаимосвязь базовых данных и использую UID, чтобы сопоставить животное со специфическими свойствами, как показано ниже . Сущность животного получает атрибут «selectedProps», в котором я храню UID, который ссылается на один из указанных объектов «Property », каждый из которых получает атрибут UID.

enter image description here

Насколько я могу наблюдать, это имеет следующие недостатки и преимущества

Downsides:

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

Преимущества:

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

Мой вопрос: я что-то упускаю? Я совершаю ужасную ошибку или, может быть, есть лучшая альтернатива?

Любая критика комментариев будет принята с благодарностью.

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

1 Ответ

0 голосов
/ 04 декабря 2018

Вот подход, на котором я остановился до сих пор, на случай, если он кому-нибудь поможет (не стесняйтесь критиковать).

Я создал объект общего свойства, предложенный @pbasdf.Преобразованная в аналогию с животными модель выглядит следующим образом.

enter image description here

У каждого животного есть отношение «многие ко многим» («свойства») к свойству,Свойство содержит как тип (Int16), так и значение (двоичные данные).На основе типа двоичное значение преобразуется в Float, String, UIColor или любой другой тип данных, соответствующий типу свойства.

Изначально я определил значение как String, но во время переключения я заметил значительное снижение производительности,В оригинальной модели свойства были специально определены.Как таковые они могут быть доступны напрямую и предоставлены в правильном типе.Однако при новой настройке требуется выполнить два дополнительных шага.1) Основываясь на типе, мы должны сначала найти правильное свойство.Для одного животного, как правило, меньше 10, но в среднем это все еще означает, что пара должна быть оценена, прежде чем будет найдена правильная.2) Преобразование общего значения в правильный тип данных также увеличивает время.Эти два шага привели к значительному увеличению времени извлечения свойств при использовании строк (10+).При использовании двоичного атрибута для хранения значения увеличение было ограничено в 3-4 раза.Конечно, если вам нужно выполнить поиск значения, строки более доступны, как упомянуто pbasdf.

Наконец, у меня есть проблема, заключающаяся в том, что сущность Animal по-прежнему принадлежит к нескольким контейнерам, что означает значительное количество входящих отношений, которыезасорять модель.К сожалению, в моей модели я не имею дело с животными и не могу просто конвертировать Jungle, Zoo и WildLifePreserve в общую сущность Enclosure.Rather Animal - это контейнер общих свойств, который предоставляет свойства для целого ряда различных объектов.

...