CODEWITHSUNDEEP
ioscore-datadatabase-design
James Webster
James Webster

Reputation: 32066

Is this pattern suitable for Core Data?

The only databases I've worked with before are MySQL so the database design of CoreData is confusing me a little bit.

Briefly, the design consists of a many-to-many relationship between people and businesses. Many people can own one business. One person can own many businesses.

In this simplified design, there are 3 tables:

PERSON       BUSINESS      OWNED BUSINESS
------       --------      --------------
id           id            personID
name         name          businessID
email        website       acquisitionDate

The OwnedBusiness table is the one that's confusing me. In MySQL, this table is used to support many-to-many relationships. I understand that CoreData doesn't require this, however I have an extra field in OwnedBusiness: acquisitionDate.

Does the extra field, acquisitionDate warrant the use of the extra entity/table? If not, where would that field go?

Upvotes: 0

Views: 521

Answers (2)

danypata
danypata

Reputation: 10175

So first of all, CoreData is not a relational db just to clear this out.

Second, I think you should have a quick look at CoreData documentation and since you are familiar with MySql it will be an easy reading and I think you will be kind of amazed by the extra features that CoreData provides.

Regarding the many-to-many relationship, CoreData support this relationship without the need of extra tables. Also the relationship are not based on ids, they are based directly on objects.

So in your case, you don't have to use the person id & business id to create the relationship, you can create the relationship in the Relationship section of your xcdatamodel, there you can set the relationship class (or Destination), an inverse to that relationship (useful thing) and of course the type of relationship (to-many, to-one).

So to answer your question, you can add it there depending on your business logic. As a short advice, pleas don't try to normalise the database as you would do on a normal MySql instance, you will loose lot of performance by normalising, this thing is often ignored by devs.

Upvotes: 1

Marcus S. Zarra
Marcus S. Zarra

Reputation: 46718

First, Core Data is not a database, full stop.

Core Data is an object graph management framework, your model in your application.

It can persist to disk in a database. It can also persist as binary, XML and just about anything else. It does not even need to persist.

Think about Core Data as an object graph only. In your example you would have a Person entity, a Business entity and a OwnedBusiness entity.

The OwnedBusiness entity would have two relationships and one property. You would not manage the foreign keys because Core Data handles that if you end up persisting to a database. Otherwise they are object pointers.

Upvotes: 17

Related Questions