Is Core Data more suitable than SQLite for server client database design?

Question

I'm having a server client database design which I'm unsure is Core Data suitable?

I have a server database which will maintain the master copy of the data and their relationship.

Each client application will have an empty client database with only relationship.

Upon the start up of the client, it will request for data from the server and try to populate it with data.

As the relationship in the client database will cause the insertion to fail, the client will compile a list of information that it is still lacking and make the necessary request until it succeed in inserting all information.

So in conclusion, client will have only a subset of data from the server.

In my design, the primary keys and relationships have to be managed by the server database.

But it seems that Core Data purposefully abstract the management of primary keys and relationships.

I can either emulate my own primary keys and relationships mechanism using Core Data. While reaping the benefit of what Core Data provides.

Or implements SQLite and handle my own data.

Answer 1

Go with Core Data. If you use SQL, you will end up duplicating a lot of Core Data functionality by hand anyway.

The key to making this work is understanding the data well enough that you can turn it into objects. Don't make the mistake of thinking in terms of tables, columns and rows when designing the Core Data entity graph. Your not trying to model the SQL database.

Instead, your trying to create a graph that mimics the relationships in the real world objects, conditions or events that the data itself represents. How the data is managed on disk is irrelevant to the design. After all, what if your data comes from multiple sources?

Once you have a good model, then all you need to do is extract the data from the server and then put the right data in an instance of the right entity and its properties. That task is always relatively trivial if you have a properly designed model.