首页 > 解决方案 > 在核心数据中存储上下文属性的最佳方式?

问题描述

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

例子:

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

每个人为其他几个人工作,并且根据他们的工作关系拥有不同的头衔,并且他们的头衔可能会在一年之间改变(如果这个细节很重要:每个人也可能同时雇用一个或几个其他人,这就是为什么一个人是雇员,但也可能是雇主)

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

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

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

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

标签: iossqlitecore-dataentity-attribute-valueobject-graph

解决方案


以您的示例为例,一种选择是创建一个Employment实体,其属性为titleandyearEnded和两个(一对一)关系Person。一种关系代表employer,另一种关系代表employee

在这两种情况下,逆关系都是对多的。一个代表 Person 是雇员的工作(所以你可以命名它employmentsTaken),另一个关系代表 Person 是 Employer 的工作(所以你可以命名它employmentsGiven)。

概括地说,这是 Apple 为具有属性的多对多关系推荐的解决方案(请参阅其文档中的“基于其语义建模关系” )。

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


推荐阅读