核心数据迁移技术：移动属性 – >build模关系
我有一个相当大的基于核心数据的数据库模式（〜20个实体，超过140个属性），它正在经历巨大的变化，因为它从我们的1.x代码库迁移到我们的2.x代码库。
我对执行轻量级迁移非常熟悉，但是对于这种特定的迁移，我有点不知所措，因为有一些实体用于将相关对象存储为实体本身的可变形属性，但是现在我想将它们迁移到实际实体。
这似乎是一个完美的例子，你应该使用一个沉重的迁移，而不是一个轻量级的，但我也不太高兴。 我不熟悉沉重的迁移，其中一个具有此数组关系转换的实体占据了数据库中约90％的行，这些数据库往往大于200 MB，我知道我们的很大一部分客户正在使用iPad 1。 再加上苹果文档和Marcus Zarra（优秀的）核心数据书中有关重度迁移的速度和内存使用情况的重复警告，使我非常谨慎，并寻找另一种方法来处理这种情况。
WWDC 2010的“掌握核心数据”会议118（ 幻灯片在这里 ，需要login，第9次到最后一张幻灯片，标题为“迁移后处理”就是我所指的）提到一种方法来解决这个问题 – 执行然后使用商店元数据标记您要执行的自定义后处理是否已完成。 我想这可能是要走的路，但是对我来说感觉有点不好（因为没有更好的词）。 另外，我担心在实践中留下的属性悬而未决。 恩。 如果我将实体foo的barArray属性移动到实体foo和实体栏之间的关系中，并且我没有删除barArray，那么barArray仍然作为一个可以写入和读取的属性存在。 解决这个问题的一个潜在的方法是通过改变它们的名字以使它们在前面被“废弃”，并且可能覆盖访问器来断言它们是否被使用，而这些属性被弃用，但是对于KVO，没有保证的编译这个解决scheme会阻止人们使用它们，而且我不愿意留下“陷阱代码”，特别是因为只要潜在客户仍然需要从1.0迁移，那么“陷阱代码”就必须存在。
这变成了比我想要更多的脑转储，为了清晰起见，我的问题是：
1）在我受到限制的情况下，迁移是一个特别糟糕的select吗？ （业务关键型应用程序，缺乏大量迁移的经验，数据库大小超过200 MB，数万行，使用运行iOS 5的iPad 1的客户）
2）如果是这样，118会话中描述的迁移后处理技术是我最好的select吗？
3）如果是这样，我怎样才能立即/最终消除那些“弃用的”属性，以便它们不再污染我的代码库？
我的build议是远离重度的移民; 句号 在iOS上它太贵，很可能会导致不可接受的用户体验。
在这种情况下，我会做一个懒惰的迁移。 创build具有关联对象的轻量级迁移。
然后进行迁移，但不要移动任何数据 。
更改新关系的访问器，以便它首先检查旧的可变形，如果可变形被填充，则将数据拉出，将其复制到新的关系，然后无可转换。
这样做会导致数据在使用时移动。
现在这个devise有一些问题。
如果你想对这些新的对象使用谓词它将是…凌乱。 你会想要做一个两回合的提取。 也就是说，用一个不会触及新对象的谓词进行提取，然后在内存中执行一个段提取操作，这样就可以将可变形移动过来。