跨商店与获取属性的关系较弱？

我想将我的参考数据与核心数据模型中的用户数据分开，以简化我的应用程序的未来更新（并且因为，我计划将数据库存储在云上，并且不需要将参考数据存储在云上，因为这是我的申请的一部分）。因此，我一直在寻找一种使用获取的属性来编码跨商店关系的方法。我还没有找到任何示例实现。

我有一个使用两种配置的核心数据模型：

• 数据模型配置1：UserData（与用户相关的实体）

• 数据模型配置 2：ReferenceData（与应用程序本身相关的实体）

我为这两个配置设置了 2 个不同的 SQLite 持久存储。

• UserData 配置（和存储）包含实体“User”

• ReferenceData 配置（和存储）包含实体“Type”和“Item”。

我想创建两个单向弱关系，如下所示：

• “用户”具有唯一的“类型”

• 一个“用户”有很多“物品”

这是我的问题：

• 我如何设置我的属性？

• 每个关系是否需要 2 个属性（一个用于存储唯一 ID，另一个用于访问我获取的结果）？

• 这种弱关系可以被秩序化吗？

• 有人能给我一个实现这个的例子吗？

作为马库斯回答的后续：

通过浏览论坛和文档，我了解到我应该使用实体实例的 URI 表示而不是 objectID。这背后的原因是什么？

// Get the URI of my object to reference 
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];

接下来，我想知道如何将我的对象 B URI (NSURL) 作为弱关系存储在我的父对象 A 中？我应该使用什么属性类型？我该如何转换这个？我听说过存档...？

然后，稍后我应该以相同的方式检索托管对象（通过取消转换/取消存档 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 对允许应用程序同步和存储在文档中的数据有软上限。

要创建跨存储的软引用（它们不需要是 SQLite，但对于一般应用程序性能来说这是一个好主意），您将需要有某种可以从另一端引用的唯一密钥；一个好的老式外键。

从那里，您可以在模型中创建一个获取的属性来引用实体。

虽然这种关系不能直接排序，但您可以通过排序索引创建顺序，或者如果它具有逻辑排序，那么您可以在检索数据后对其进行排序（我为此使用方便的方法，返回排序的数组而不是集合）。

我可以举一个例子，但你确实走在正确的道路上。唯一有趣的部分是迁移。当您检测到迁移情况时，您将需要独立迁移每个商店before您建立了核心数据堆栈。这听起来很棘手，但实际上并不难实现。

Example

假设您在用户存储中有一个 UserBar 实体，在参考存储中有一个 RefBar 实体。然后，RefBar 将与 UserBar 建立 fetchedProperty“关系”，从而创建 ToOne 关系。

UserBar
----------
refBarID : NSInteger

RefBar
--------
identifier : NSInteger

然后，您可以在建模器中的 RefBar 实体上创建一个获取的属性，其谓词为：

$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

创建 ToMany 是相同的，只是您的便捷方法将返回一个数组，并且您将在返回数组之前对数组进行排序。

As 希思·博德斯提到过，可以add排序到NSFetchedProperty如果你愿意，但你必须用代码来完成。就我个人而言，我一直觉得它很浪费并且不使用该功能。如果我可以在建模器中设置排序，可能会更有用。

使用对象 ID

我不建议使用 ObjectID 或 URIRepresentation。 ObjectID（以及该 ObjectID 的 URIRepresentation）可以并且将会改变。每当您迁移数据库时，该值都会发生变化。创建一个不变的 GUID 会更好。

弱关系

您只需要关系 M 端的一个值来存储外部标识符。在您的对象子类中，您只需要实现检索对象（或多个对象）的访问器。