初识Core Data
“一个庞然大物，肤色黝黑，面无表情，应该不好相处。”这是Core Data给我的第一印象。但据说它会给别人提供很多的服务，顿时让我感到一股浓浓的PY味道。为了重返仙界，我也顾不了太多，脱了衣服对它说：“来的匆忙，见面礼没来得及买。”没想到它到够仗义：“既然是Runtime的兄弟，那也就是我的兄弟，不要见外，赶紧穿上衣服，一会儿先带你去洗个澡，算是为你接风了。”
来找Core Data当然不是为了潇洒，第二天，我便向它请教了一些问题。
数据类型
Core Data是用来管理数据持久化存储的，其中Transformable数据类型比较特别，是用来描述OC中任何类对象的。这么说有点别扭，直接举例：我们可以用这个类型保存UILabel类对象，也可以是自定义的类对象，只要实现了NSCoding协议即可，这简直就是酷炫吊炸天。
每个属性的设置选项
- Indexed选项是系统用来提升搜索效率的，但在底层的持久存储区中会额外的占用内存空间，大小视数据量而定，这是典型的用空间换取时间的做法；同时Indexed减慢了数据插入和删除的速度，因为每次插入和删除都需要更新Indexed，Indexed越多，性能下降越大。具体的取舍，要根据业务需求来定。
- 当数据类型是Binary Data时，若我们选择了Allows External Storage选项，Core Data就会把比较大的数据（超过1MB）保存在SQLite持久存储区域外了，如保存照片、音频、视频等。这样做的目的当然是为了提高数据存取效率。
关系
关系型数据库早就听说过，就是多个数据表之间可以有引用关系。Core Data所说的关系也大同小异。使用关系可以大幅降低数据所占用的存储空间。
在Xcode中我们可以设置关系的Type字段为To One或者To Many，如果设置了To Many，则在生成的NSManagedObject子类中，相关属性类型为NSSet（无序且没有重复元素的集合）；若还选择了Ordered选项，则相关属性类型为NSOrderedSet（有序且没有重复元素的集合）。
假如有Department与Personnel两个实体，之间的关系如图：
还有一个对关系有重要描述的字段Delete Rule，它有4个选项：
- No Action 这个删除规则很少使用，它会导致关系对象处于不一致的状态。例如删除了某个Personnel对象，但是Department对象仍有指向这个Personnel对象的关系，这就需要手动的去设置实时的关系，以确保彼此都指向有效的对象。
- Nullify 这个删除规则使有关系的对象之间失去关系，但双方仍都存在。例如把Personnel实体中的关系的删除规则设置为Nullify，则删除某个Personnel对象后，它就与Department对象没有关系了，但是这个Personnel对象仍然存在，这时候就可以将此对象再关联到其他的Department对象上，完成关系的转移。
- Cascade 这个删除规则会沿着关系来传播删除操作。例如把Department实体中的关系的删除规则设置为Cascade，则删除某个Department对象后，与它有关系的Personnel对像也都会被删除。
- Deny 这个删除规则在有关系的对象之间产生一个约束（某种情况拒绝删除操作）。例如把Department实体中的关系的删除规则设置为Deny，那么当删除某个Department对象并试图将改动保存时，若仍有Personnel对象与之有关系，则会引发validation error（cocoa error 1600）。所以当采用了Deny规则，在删除对象前就要确保没有关系对象再与之有关联了。
⚠️只有在调用了save:方法后，系统才会去实施删除规则。
为了避免程序崩溃，在删除规则为Deny时，进行删除操作前可以先调用NSManagedObject中的validateForDelete:方法去判断是否能够安全的删除对象。
NSError *error;
if ([oneDepartment validateForDelete:&error]) {
[_context deleteObject:oneDepartment];
} else {
NSLog(@"Failed to delete %@, Error: %@", oneDepartment, error.localizedDescription);
}
Core Data告诉我，掌握了这些招式，就可以继续踏上修仙的大道了。我心里想，就这么点把戏，就打发我走吗？但碍于在别人屋檐下，我只好低头，于是决定给它点甜头尝尝。
关注微信公众号CodingArtist，可以第一时间得到文章更新通知! _
