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

Question

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

示例:

一个对象就是一个人(可能=Employer/=Employee)

每个人都为其他几个人工作，并且在他们的工作关系中拥有不同的头衔，并且他们的头衔可能会从一年更改到另一年(如果这个细节很重要:每个人也可以同时雇用一个或几个其他人，这就是为什么一个人是雇员但也可能是雇主的原因)

所以我的对象的一个​​属性是“标题 vs 雇主 vs 结束年份”

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

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

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

Answer 1

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

在这两种情况下，反向关系都是一对多的。一个代表人员是雇员的工作(因此您可以将其命名为 employmentsTaken )，另一个关系代表人员是雇主的工作(因此您可以将其命名为 employmentsGiven )。

一般来说，这是 Apple 为具有属性的多对多关系推荐的解决方案(请参阅 their documentation 中的“基于语义建模关系”)。

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