sqlitepo(sqlite) vs core data

sqlitepersistentobjects的活跃度很低，在这个stackoverflow的帖子中，coredata vs sqlitepersistentobjects

就算这个project已经被作者否定了，但下段这个豪情的叙述，推销的开场白，还是很有意思，或许应该将之记下。。

 

“Wouldn't it be nice if your Objective-C data objects just knew how to save and load themselves? It'd be nice if you could just call "save" and trust that your object would save itself properly somewhere, and that when you wanted to load it back in, you could just call a class method to retrieve the object or objects you wanted?

Well, now you can. This project uses the objective-C runtime to implement a pattern similar to ActiveRecord, but driven by the object's properties rather than the tables in the database.

The objects are completely self-contained - you do not need to write SQL or even create a SQLite file. You just subclass an existing class, and your model objects inherit the ability to load and save themselves from the database.”

 

SQLPO(sqlitepersistentobjects)的设计初衷是可以以OO的方式的存储和装载数据，无须过的关注的数据操作本身，是sqlite的orm实现。如果你用到sqlite存储数据，而又不想写那些操作语句，对于这种轻量级的应用，使用SQLPO可能是个很好的选择。SQLPO是在coredata之前产生的，当IOS3.0里面有了core data framework之前，作者也就放弃了SQLPO的开发了。

CORE DATA，apple为了ios引入的framework，这是一个对象实例管理框架，定义了对象以及对象之间的关系，这被称为object graph。至于对象数据本身是怎么存储的，core data的存储可以是使用sqlite 也可以其他的关系数据库或者用户自定义的二进制格式，也就是说core data 底层存储对上层透明（在创建NSPersistentStoreCoordinator时可以指定相关存储方式）。本质上core data并不是sqlite的orm实现，。

如果仅想以orm的方式的操作sqlite数据库，那么就使用SQLPO（或者其他类似的lib）。若你的任务不限制于此(如有对象（表）之间关系)，可能就要尝试下coredata。

另外若你的所存的数据可能会在其他平台上用到，那就直接使用sqlite（SQLPO）或者在使用coredata时指定persistentStoreType为NSSQLiteStoreType(此时相关sqlite数据库文件在应用的沙盒document目录下)
。关于sqlite3与coredata的关系，可以参照下面的帖子

core-data-vs-sqlite-3 

这个其中的非常好的描述：

"

Although Core Data is a descendant of Apple's Enterprise Object Framework, an object-relational mapper (ORM) that was/is tightly tied to a relational backend, Core Data is not an ORM. It is, in fact, an object graph management framework. It manages a potentially very large graph of object instances, allowing an app to work with a graph that would not entirely fit into memory by faulting objects in and out of memory as necessary. Core Data also manages constraints on properties and relationships and maintins reference integrity (e.g. keeping forward and backwards links consistent when objects are added/removed to/from a relationship). Core Data is thus an ideal framework for building the "model" component of an MVC architecture.

To implement its graph managemet, Core Data happens to use sqlite as a disk store. It could have been implemented using a different relational database or even a non-relational database such asCouchDB. As others have pointed out, Core Data can also use XML or a binary format or a user-written atomic format as a backend (though these options require that the entire object graph fit into memory). If you're interested in how Core Data is implemented on an sqlite backend, you might want to check out OmniGroup's OmniDataObjects framework, an open source implementation of a subset of the Core Data API. The BaseTen framework is also an implementation of the Core Data API using PostgreSQL as a backend.

Because Core Data is not intended to be an ORM for sqlite, it cannot read arbitrary sqlite schema. Conversely, you should not rely on being able to read Core Data's sqlite data stores with other sqlite tools; the schema is an implementation detail that may change.

Thus, there is not really any conflict between using Core Data or sqlite directly. If you want a relational database, use sqlite (directly or via one of the Objective-C wrappers such as FMDB), or a relational database server. However, you may still want to learn Core Data for use as an object graph management framework. In combination with Apple's controller classes and key-value binding compatible view widgets, you can implement an complete MVC architecture with very little code.

"