我正在使用Core Data来存储对象。对我来说，最有效的可能性（即最佳执行效率，所需代码最少，最大程度的简化以及与现有功能/库/框架的最大兼容性）根据上下文为每个对象存储不同的属性值，而又不能知道上下文是是预定义的，会被用户大量修改并不断对其进行编辑吗？
示例：
一个对象就是一个人（可能=雇主/ =雇员）
每个人都为其他几个人工作，并且根据其工作关系拥有不同的头衔，并且头衔可能会从一年更改为另一年（如果这一细节很重要：每个人还可能同时雇用一个或几个其他人，这就是为什么一个人是雇员但有可能也是雇主的原因
所以我对象的一个属性是“标题vs雇主vs年末”
根据目前的知识，我能做的最好的事情就是将所有三个元素保存为一个字符串，这将是分配给每个对象的属性值，并不断地解析该字符串以使用它，但这具有以下特点（巨大）的缺点：
（1）执行速度过慢和能源消耗增加。使用此上下文属性是我预期的App核心功能的核心（因此，实际上每分钟将使用10-100次）。必须不断解析这些信息才能使用它，这会增加不必要的处理，我非常想避免 （2）多余的编码开销。每次将使用此中心信息时（即非常频繁地），将此上下文属性另存为字符串将使我不必要地额外编码。 （3）不适当的复杂性和潜在的不兼容性。它还会增加不必要的复杂性，并且偏离预期的实践，将摆脱核心数据的优势。
在没有上述缺点的情况下实现目标的最有效方法是什么？
答案 0 :(得分：3)
以您的示例为例，一个选择是创建一个 volumeBar.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() {
@Override
public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
}
@Override
public void onStartTrackingTouch(SeekBar seekBar) {
}
@Override
public void onStopTrackingTouch(SeekBar seekBar) {
}
});
实体，该实体具有Employment和title的属性以及与yearEnded的两个（一对一）关系。一种关系表示Person，另一种关系表示employer。
在两种情况下，逆关系都是很多的。一个代表人是雇员的工作（所以您可以将其命名为employee），另一种关系是代表人是雇主的工作（因此您可以将其命名为employmentsTaken）。
概括地说，这是Apple针对具有属性的许多关系建议的解决方案（请参阅their documentation中的“基于语义建模关系”）。
是否能够解决您的问题中列出的所有问题，我留给您进行试验：如果每分钟发生10到100次变化，则获取请求以及创建/更新/删除中间件的开销（{{1 }}）实体可能比您的字符串表示形式还差。