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?
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.