我有一个相当大的基于 Core Data 的数据库模式（约 20 个实体，超过 140 个属性），当它从我们的 1.x 代码库迁移到我们的 2.x 代码库时，它正在经历巨大的变化。
我对执行轻量级迁移非常熟悉，但我对这个特定的迁移有点困惑，因为有一些实体用于将相关对象存储为实体本身的可转换属性，但现在我想将它们迁移到实际实体.
这似乎是一个完美的例子，说明何时应该使用重迁移而不是轻量迁移，但我对此也不太满意。我不熟悉大量迁移，具有此数组的实体之一 -> 发生建模关系转换占用了数据库中约 90% 的行，这些数据库的大小往往超过 200 MB，我知道我们的大部分客户都在使用 iPad 1s。再加上 Apple 文档和 Marcus Zarra 的（优秀的）Core Data 书中关于大量迁移的速度和内存使用的反复警告，让我非常谨慎，并寻找另一种方法来处理这种情况。
WWDC 2010 的“掌握核心数据”第 118 场会议（幻灯片在这里，需要登录，倒数第 9 张幻灯片，标题为“迁移后处理”是我所指的）提到了一种解决此问题的方法 - 执行迁移，然后使用存储元数据来标记是否或未完成您要执行的自定义后期处理。我认为这可能是要走的路，但对我来说感觉有点 hacky（因为没有更好的词）。另外，我担心会留下那些在实践中被弃用的属性。前任。如果我将实体 foo 的 barArray 属性移动到实体 foo 和实体 bar 之间的关系中，并且我将 barArray 设为 nil，barArray 仍然作为可以写入和读取的属性存在。解决此问题的一种潜在方法是通过将这些属性的名称更改为“已弃用”来表示已弃用这些属性
这变成了比我预期的更多的大脑转储，所以为了清楚起见，我的问题是：
1）在我工作的限制下，大量迁移是一个特别糟糕的选择吗？（业务关键型应用程序，缺乏大量迁移经验，数据库大小超过 200 MB，数万行，使用运行 iOS 5+ 的 iPad 1 的客户）
2) 如果是这样，是会话中描述的迁移后处理技术118我最好的选择？
3）如果是这样，我怎样才能立即/最终消除那些“弃用”的属性，以便它们不再污染我的代码库？