Cross-Store与Fetched Properties的弱关系？
我想在我的核心数据模型中将我的参考数据与我的用户数据分开，以简化我的应用程序的未来更新（因为我打算将数据库存储在云上，并且不需要将参考数据存储在云上这是我的应用程序的一部分）。 因此，我一直在寻找一种使用提取的属性来编码跨商店关系的方法。 我还没有find任何这样的示例实现。
我有一个使用2种configuration的核心数据模型：
-
数据模型configuration1：UserData（相对于用户的实体）
-
数据模型configuration2：ReferenceData（相对于应用程序本身的实体）
我为这两个configuration设置了两个不同的SQLite持久性存储。
-
UserDataconfiguration（和存储）包含实体“用户”
-
ReferenceDataconfiguration（和存储）包含实体“types”和“项目”。
我想创build两个单向弱关系如下：
-
“用户”具有唯一的“types”
-
一个“用户”有很多“项目”
这是我的问题：
-
我如何设置我的属性？
-
我是否需要每个关系的2个属性（一个用于存储唯一ID，另一个用于访问我提取的结果）？
-
这种弱关系可以下令吗？
-
有人能给我一个这个例子的实现吗？
作为马库斯的回答的后续：
通过论坛和文档看，我读了我应该使用我的实体实例的URI表示而不是objectID。 这背后的原因是什么？
// Get the URI of my object to reference NSURL * uriObjectB [[myObjectB objectID] URIRepresentation]; 接下来，我想知道，如何将我的对象B URI（NSURL）存储在我的父对象A中作为弱关系？ 我应该使用哪种属性types？ 我如何转换？ 我听说过档案…？
然后，稍后我应该以相同的方式检索托pipe对象（通过未转换/取消归档URIRepresentation）并从URI获取对象
// Get the Object ID from the URI NSManagedObjectID* idObjectB = [storeCoordinator managedObjectIDForURIRepresentation:[[myManagedObject objectID] URIRepresentation]]; // Get the Managed Object for the idOjectB ...
最后但并非最不重要的是，我在我的实体A中声明了两个属性，一个用于保存URI需求，另一个用于检索直接对象B？
NSURL * uriObjectB [objectA uriObjectB]; ObjectB * myObjectB = [objectA objectB];
正如你可以阅读，我真的很想念一个简单的例子来实现这种弱关系！ 我真的很感谢一些帮助。
分割数据是迄今为止的正确答案。 参考数据不应该与云同步，尤其是因为iCloud软件已经允许应用程序同步并存储在文档中。
为了在商店中创build软引用（它们不需要是SQLite，但是它对于一般应用程序性能来说是个好主意），您将需要某种可以从另一端引用的唯一键; 一个好的老式的外键。
从那里你可以在模型中创build一个提取的属性来引用实体。
虽然这种关系不能直接sorting，但是你可以通过一个sorting索引来创build顺序，或者如果它有一个逻辑sorting，那么你可以在检索数据后对它进行sorting（我使用便捷方法来返回一个有序数组而不是一个集合）。
我可以build立一个例子，但你真的走在正确的轨道上。 唯一有趣的部分是移民。 当您检测到迁移情况时，您将需要在build立核心数据堆栈之前独立迁移每个商店。 这听起来很棘手，但它确实不难完成。
例
试想一下，用户存储中有一个UserBar实体，而参考存储中有一个RefBar实体。 然后，RefBar将与用户栏具有fetchedProperty“关系”，从而创buildToOne关系。
UserBar ---------- refBarID : NSInteger RefBar -------- identifier : NSInteger
然后，您可以在build模器的RefBar实体上创build一个提取的属性，其谓词为：
$ FETCHED_PROPERTY.refBarID ==标识符
让我们把这个谓词命名为“userBarFetched”
现在，这将返回一个数组，所以我们想添加一个方便的方法到RefBar
@class UserBar; @interface RefBar : NSManagedObject - (UserBar*)userBar; @end @implementation RefBar - (UserBar*)userBar { NSArray *fetched = [self valueForKey:@"userBarFetched"]; return [fetched lastObject]; } @end
创build一个ToMany是一样的，除了你的便捷方法会返回一个数组，并且在返回之前对数组进行sorting。
正如Heath Borders所提到的，如果你愿意的话，你可以添加一个NSFetchedProperty的sorting，但你必须在代码中完成。 就我个人而言，我一直觉得这是浪费，不要使用这个function。 如果我可以在build模器中进行sorting，这可能会更有用。
使用ObjectID
我不build议使用ObjectID或URIRepresentation。 ObjectID（以及因此ObjectID的URIR表示）可以并将改变。 每当你迁移一个数据库的值将会改变。 创build一个不变的GUID要好得多。
弱关系
您只需要关系的M一侧的一个值，并存储外部标识符。 在你的对象子类中，你只需要实现访问器来检索对象（或对象）。
我会去只有一家商店。
为了将东西存储在云中，无论如何都要将数据序列化，无论是JSON还是SQL语句，或者您喜欢的任何scheme。
您将需要用户设备上的数据的本地副本，以便他可以快速和脱机地访问它。 云存储可以只有用户实体，而本地存储（应用程序的一部分）也可以有参考实体。
我有一个类似的项目，有一个巨大的参考商店（20000条logging），地理信息和用户生成的内容（“post”）。 我使用一个商店。 当我运送应用程序时，“posts”实体也被定义，但是是空的。 当我更新数据模型时，我只是在发货前重新生成整个参考商店。
在这里，我绝对没有理由去跨店解决scheme。