Как преобразовать существующую схему MySQL в базовые данные - PullRequest
Новая
       24

Как преобразовать существующую схему MySQL в базовые данные

4 голосов
/ 19 июля 2011

У меня есть база данных MySQL, и я хотел бы иметь подобную структуру в Core Data. Я очень новичок в использовании Core Data с Xcode. У меня есть несколько фундаментальных вопросов, если я поступаю правильно.

Моя Mysql DB выглядит примерно так: 

table.caveconditions
  visibilityID
  percolationID
  xxxx

table.visibility
  visibilityID
  visibilityValue

... и так далее. Затем я бы связал таблицы, используя JOINS

Теперь я провел моделирование Базовых Данных, как это, но я не совсем уверен, что это правильный подход.

Было бы здорово, если бы кто-то из вас мог сказать мне, если это правильный способ сделать это. В конце я хотел бы использовать строки JSON для вывода таблицы mysql в основные данные.

Большое спасибо Chris

enter image description here

Я создал новую схему. Это правильно?

enter image description here

Ответы [ 2 ]

4 голосов
/ 19 июля 2011

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

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

Каждый объект в Базовых данных автоматически универсально уникален. Это означает, что когда вы создаете отношение от одного объекта к другому, это отношение конкретно идентифицирует конкретный уникальный объект.

Это означает, что вам нужен только атрибут типа caveID в реальной сущности, который caveID обозначает, который в этом случае (предположительно) является сущностью Caves. Вам не нужен атрибут в сущности CavesConditions или любой другой сущности, которая имеет отношение к сущности "Пещеры".

(Если бы xxxID были просто артефактами SQL, на самом деле они не нужны в Core Data, если только некоторые внешние базы данных, с которыми ваше приложение взаимодействует, не требуют их.)

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

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

В этом случае Caves должно быть Cave, Countries должно быть Country и так далее.

Отношения названы в честь сущности, на которую они нацелены. Это не очевидно сразу, но каждое взаимное отношение (по умолчанию) в редакторе визуальной модели данных на самом деле представляет собой два отношения, потому что для каждой стороны существует одно описание отношений. У каждой стороны есть название целевого объекта. По соглашению отношения «один к одному» имеют единственное имя, а отношение «многие» имеет множественное имя.

Итак: 

Caves.relConditions<-->>CaveConditons.getCave

... станет 

Cave.conditons<-->>CaveConditon.cave

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

1 голос
/ 19 июля 2011

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

...