Ease of use. In fact, a mature project must be a data persistence package, so the bottom of the use of core data or sqlite, should not be the business logic developers concerned. Therefore, even people who are accustomed to writing SQL queries should avoid writing SQL statements directly in the business logic.
Storage performance, in the write performance, because all are used in the SQLite format as a disk storage format, so its performance is the same, if you think with core data write slow, it is likely that you use SQLite when you write the content of each piece of data without core data when more, Or when you write in bulk, the save is called every time you write a message.
Query performance, core data is compatible with a variety of backend formats, so when querying, its available statements are less than the direct use of sqlite, so some fetch is not actually performed in SQLite. However, this will not necessarily reduce the efficiency of the query. Because the iphone flash memory speed is still very fast. My experience is that most of the time, when the memory is not very tense, it is often faster to fetch all the data from an entity and then make the filter in memory more quickly than using predicate in fetch. If you think the query is slow, it is likely that the query method has a problem, you can open the debug mode of core data to see how many SQL statements executed, I believe most of them can be overridden by the core data to avoid the call way.
One of the big pain points of core data is that when people work together, the model of managing coredata needs to be careful, especially when merging, his data model is in XML format, and manual resolve is more annoying.
Core data has other advantages that SQL does not have, such as support for undo, and multiple context implementations sketchbook similar functionality. The row cash optimized for ManagedObject.
In addition, core data is multi-threaded, but requires thread confinement implementation, using multithreading can be maximized to prevent blocking the main thread.
1. If your project size is large, use coredata can reduce your storage management of a lot of work, otherwise you may need to write a lot of data model to the database operation code.
2. Your data structure changes, data migration time CoreData can help you to complete automatically, with SQLite you need to write code to complete.
3.coreData also has some other efficiency optimizations, such as deferred writes.
For myself, in general, if there is no complex query requirements, and the amount of data is relatively small, I will use files to do storage, self-feeling relatively clean. If it involves more data, but the structure of a single, less than the table, logic is relatively simple with sqlite is also good, but if your table is more, operation is more, there is the need to upgrade the migration, recommend the use of CoreData bar.
The difference between SQLite and CoreData