How to convert an existing MySQL schema to master data

Question

I have a MySQL database and would like to have a similar structure in Core Data. I am very new to using Core Data with Xcode. I have a few fundamental questions if I am doing the right thing.

My Mysql DB looks something like this:

table.caveconditions visibilityID percolationID xxxx table.visibility visibilityID visibilityValue 

... and so on. Then I connected the tables using JOINS

Now I have done Core Data modeling this way, but I'm not quite sure if this is the right approach.

It would be great if one of you could tell me whether to do it right. In the end, I would like to use JSON strings to output the mysql table to the main data.

Thanks a lot Chris

I created a new circuit. Is it correct?

Answer 1

It looks good, with the exception of all the attributes "xxxID", for example. caveID . You also need to follow naming conventions.

You have the same attribute names with (presumably) the same values ​​in two or more entities. This is necessary in SQL for joins, but in Core Data, it is handled by objects and relationships.

Each object in Core Data is automatically universal. This means that when you create relationships from one object to another, that particular relationship is identified on a particular unique object.

This means that you only need an attribute of type caveID in the actual object, which stands for caveID , which in this case is (presumably) a Caves object. You do not need an attribute in the CavesConditions object or any other object that is related to the Caves entity.

(If xxxID were just SQL artifacts, they are not really needed in Core Data, if some external database that your application interacts with requires them.)

A good rule to use is that any particular value should be displayed only on one side of the relationship and, ideally, only once in the entire data model.

Naming conventions are slightly different from SQL. The Core Data object is not a table. An entity is more like a class. Each entity must describe one instance of the managed entity. How many of these instances end in the graph of objects does not matter. Therefore, object names are unique.

In this case, Caves should be Cave , Countries should be Country and so on.

Relations are named after the object they are aimed at. This is not immediately obvious, but each mutual relationship (by default) in the visual data model editor is actually two relationships, because for each side there is one description of the relationships. Each side has a target name. Under the one-to-one conventions, they have a singular name, and the many relationship has a plural name.

So:

 Caves.relConditions<-->>CaveConditons.getCave 

... will become

 Cave.conditons<-->>CaveConditon.cave 

Naming conventions are important because Objective-C uses conventions to generate and search for access methods.

Answer 2

CoreData is NOT a database. Alter your data as easily as you can and in a way that matches the way it will be used in your application, and don’t think about joins or structure-based optimizations. You have no control over the underlying schema of the CoreData object model. This is the most difficult concept that you must overcome when you start using CoreData, but once you do, you will be better off.