在核心数据中存储上下文属性的最佳方式？

Question

我正在使用 Core Data 来存储对象。对我来说，根据上下文为每个对象存储不同属性值的最有效可能性是什么（即最佳执行效率、所需代码最少、最简单以及与现有函数/库/框架的最大兼容性），知道上下文不能预定义的，会成群结队，不断被用户编辑吗？

例子：

一个对象是一个人（可能 =Employer / =Employee）

每个人为其他几个人工作，并且根据他们的工作关系拥有不同的头衔，并且他们的头衔可能会在一年之间改变（如果这个细节很重要：每个人也可以同时雇用一个或几个其他人，这就是为什么一个人既是雇员又可能是雇主的原因）

所以我的对象的一个​​属性是“Title vs Employer vs Year Ended”

根据我目前的知识，我能做的最好的事情是将所有三个元素一起保存为一个字符串，该字符串将是分配给每个对象的属性值，并不断解析该字符串以便能够使用它，但这具有以下内容 (巨大的）缺点：

(1) 过度减慢执行速度和增加能源消耗。使用这个上下文属性是我预期应用程序核心功能的核心（因此它实际上每分钟会使用 10-100 次）。必须不断解析这些信息才能使用它会增加我非常希望避免的过度处理 (2) 过度的编码开销。将这个上下文属性保存为一个字符串，每次我使用这个中心信息（即非常频繁）时，我都需要额外的编码。 (3) 过度复杂和潜在的不兼容性。它还会增加过度的复杂性，并且会偏离预期的做法，从而失去 Core Data 的优势。

在没有上述缺点的情况下，实现我的预期目的的最有效方法是什么？

Answer 1

以您的示例为例，一种选择是创建一个Employment 实体，具有title 和yearEnded 的属性以及与Person 的两个（一对一）关系。一种关系代表employer，另一种关系代表employee。

在这两种情况下，反向关系都是对多的。一个表示 Person 是雇员的工作（因此您可以将其命名为 employmentsTaken），另一个关系表示 Person 是 Employer 的工作（因此您可以将其命名为 employmentsGiven）。

概括地说，这是 Apple 推荐用于具有属性的多对多关系的解决方案（请参阅 their documentation 中的“基于其语义建模关系”）。

这是否会解决您的问题中列出的所有问题，我留给您进行实验：如果事情每分钟发生 10-100 次变化，那么获取请求和创建/更新/删除中间体的开销 (Employment ) 实体可能比您的字符串表示形式更糟糕。