1

I have a complex iPad app moving to use Core Data. I receive data from a server which has foreign keys built into the various tables to represent relationships between tables (entities).

As I rewrite the app to use Core Data, should I maintain the foreign key structure and create my own accessors, or convert them to Core Data relationships or use both? Seems double the work. I already have the data to link two tables that I potentially need to maintain for data I send back to the server. Yet Core Data will create its own keys for relationships. It duplicates information and could get out of sync.

I could: 1. Keep the existing attributes to represent relationships between tables and write my own fetches as needed. 2. Build an object graph as I receive the data from the server and use core data relationships . 3. Use a hybrid, sometimes foreign key attributes and sometimes relationships depending on need.

Is there a typically approach used for Core Data applications receiving most of their data from a server?

David
  • 2,770
  • 5
  • 35
  • 43

1 Answers1

1

If you are going to use core data instead of sqllite, then convert to Core Data. Remember, CoreData is not just a relational database. It is used to persist an object graph. Thus, the way you lay our your data structures may be quite different.

Typically, you may have more de-normalized data in a Core Data application, but really, you should remap your data as you want it to be used in your application. Then you will know the real answer. However, I do not think I'd leave foreign keys... I'd use relationships because that's how core data will fit best.

Jody Hagins
  • 27,943
  • 6
  • 58
  • 87