我想在我的Core data模型中分离我的参考数据和我的用户数据，以简化我的应用程序的未来更新(因为，我计划将数据库存储在云中，没有必要将参考数据存储在云中，因为这是我应用程序的一部分)。因此，我一直在寻找一种使用获取的属性来编写跨存储关系的方法。
我有一个核心数据模型使用2个配置:
-
数据模型配置1:UserData(实体相对于用户)
-
数据模型配置2:ReferenceData(相对于应用程序本身的实体)
我为两个配置设置了2个不同的SQLite持久存储
-
UserData配置(和存储)包含实体"User"
-
ReferenceData配置(和存储)包含实体"Type"one_answers"Item"。
我想创建两个单向弱关系，如下所示:
-
"用户"具有唯一的"类型"
-
一个"用户"有许多"项目"
以下是我的问题:
-
我如何设置我的属性?
-
我是否需要2个属性为每个关系(一个用于存储唯一ID和另一个访问我获取的结果)?
-
这种弱关系是有序的吗?
-
有人能给我一个例子实现这个吗?
作为Marcus回答的后续:
通过论坛和文档，我读到我应该使用我的实体实例的URI表示而不是objectID。这背后的原因是什么?
// Get the URI of my object to reference
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];
接下来，我想知道，我如何将我的对象B URI (NSURL)作为弱关系存储在我的父对象A中?我应该使用什么属性类型?怎么转换呢?我听说过存档…
?然后，稍后我应该以相同的方式检索托管对象(通过unconvert/unarchive的URIRepresentation)，并从URI
获取object// 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对允许应用程序同步和存储在文档中的内容有软上限。
创建跨商店的软引用(他们不需要是SQLite，但这是一个好主意，一般应用程序的性能)，你需要有某种唯一的键，可以从另一边引用;一个很好的老式外键。
从那里你可以在模型中创建一个被获取的属性来引用实体。
虽然这种关系不能直接排序，但你可以通过排序索引创建顺序，或者如果它有一个逻辑排序，那么你可以在检索数据后对它进行排序(我使用方便的方法，返回一个排序数组而不是一个集合)。
我可以举个例子，但是你的思路是对的。唯一有趣的部分是迁移。当检测到迁移情况时，需要在构建核心数据堆栈之前独立迁移每个存储。这听起来很棘手，但实际上并不难做到。
假设你在用户存储区有一个UserBar实体，在引用存储区有一个RefBar实体。然后，RefBar将与UserBar建立fetchedProperty"关系"，从而创建ToOne关系。
UserBar
----------
refBarID : NSInteger
RefBar
--------
identifier : NSInteger
然后你可以在modeler中的RefBar实体上创建一个已获取的属性，谓词为:
FETCHED_PROPERTY美元。refBarID == identifier
让名字谓词"userBarFetched"
这会返回一个数组所以我们想给RefBar添加一个方便的方法
@class UserBar;
@interface RefBar : NSManagedObject
- (UserBar*)userBar;
@end
@implementation RefBar
- (UserBar*)userBar
{
NSArray *fetched = [self valueForKey:@"userBarFetched"];
return [fetched lastObject];
}
@end
创建一个ToMany是相同的，除了您的便利方法将返回一个数组，并且您将在返回它之前对数组进行排序。
正如Heath Borders所提到的，如果您愿意，可以向NSFetchedProperty添加排序，但必须在代码中完成。就我个人而言，我一直觉得这很浪费，所以不使用这个功能。如果我能在建模器中设置排序，可能会更有用。
使用ObjectID
我不建议使用ObjectID或URIRepresentation。ObjectID(以及该ObjectID的URIRepresentation)可以并且将会改变。每当迁移数据库时，该值都会发生变化。您最好创建一个不可更改的GUID。
弱关系
在关系的M端只需要一个值，该值存储外部标识符。在对象子类中，您只需要实现检索对象(或多个对象)的访问器。
我只支持一家商店。
要在云中存储内容，无论如何都必须将数据序列化，可以是JSON或SQL语句，也可以是您喜欢的任何模式。
您将需要用户设备上数据的本地副本，以便他可以快速脱机访问它。云商店只能有用户实体，而本地商店(应用程序的一部分)也可以有引用实体。
我有一个类似的项目，一个巨大的参考存储(20000条记录)与地理信息，和用户生成的内容("帖子")。我用的是单店。当我发布应用程序时，"posts"实体也被定义，但为空。当我更新数据模型时，我只是在发布之前重新生成整个参考存储。
我认为绝对没有理由在这里采用跨商店解决方案。