Core data 核心数据继承和关系

我对核心数据中的继承和关系有点困惑，我希望有人能走上正确的道路。在我的应用程序中，我创建了3个实体，它们都没有（也不应该有）公共属性，但是用户所做的所有工作都会有一个保存和加载按钮。根据我的理解，我需要将所有实体“工作”包装到一个对象中，该对象将用于保存和加载，我的问题是，我是否需要在实体之间创建关系？因为我必须以某种方式将它们联系起来，这对我来说是有意义的。我的逻辑正确吗

我正在实施一个预算计算器，为了让每个人都了解我的问题，我将给出一个实际例子，如果我的逻辑不正确，请纠正我：

假设你是一个水果销售商，因此拥有一个客户数据库和一个包含你所销售水果种类的水果数据库是很正常的。根据我的理解，这里有两个实体：

客户端的属性名为：

名称

，

地址

，

电话

，

电子邮件

，等等

库存属性名为：

名称

，

重量

，

库存

，

成本

，

供应商

等

预算，属性名为：

名称

，

金额

，

类型

，

成本

，

交付

，等等

我没有把所有的属性都放进去，因为我认为你明白了。我的意思是，正如你所看到的，我只能继承两种财产；其余的则不同。所以，如果我为一个客户做预算，我可以有我想要的任意多的客户和股票数量，但是实际预算呢

---

如果我的解释不是很清楚，我很抱歉，但如果是……我应该建立什么样的关系？我认为

客户

和

预算

有联系。你有什么建议吗？

这不完全正确，但有些部分是正确的。我将您的问题分为三个部分：关系、继承和托管对象上下文，希望能帮助您分别理解每个部分：

关系 关系通常用于表示一个实体可以“属于”另一个实体（即员工可以属于一家公司）。您可以设置多个一对多关系（即员工属于一家公司和一位老板），也可以设置反向关系（最好用“拥有”或“拥有”来描述，例如“一家公司有许多员工”）

根据您的需要，还有许多甚至更复杂的关系，以及一整套删除规则，您可以在删除关系中的实体时告诉系统遵循这些规则。刚开始的时候，我发现坚持一对一和一对多的关系是最容易的，就像我上面描述的那样

遗产 继承最好描述为一种基本模板，用于其他更具体的实体。您正确地指出，您可以使用继承作为一种协议来定义一些跨多个实体通用的基本属性。一个很好的例子是有一个基类'Employee'，属性'name'，'address'和'start date'。然后，您可以创建从该员工实体继承的其他实体，如“营销代表”、“人力资源”、“销售代表”等，这些实体都具有“名称”、“地址”和“开始日期”等公共属性，而无需在每个实体上创建这些属性。然后，如果要更新模型并添加、删除或修改公共属性，可以在父实体上执行此操作，其所有子实体将自动继承这些更改

托管对象上下文（即保存） 现在，转到问题/陈述的另一部分：将所有实体包装到一个对象中，该对象将用于保存和加载。您不需要创建此对象，核心数据使用NSManagedObjectContext（简称MOC）专门用于此目的。MOC的任务是跟踪您创建、删除和修改的对象。为了保存更改，只需在MOC上调用

save:

方法

---

如果您发布您的实体以及它们所做的事情，我可能能够帮助您提出在核心数据中设置实体的方法建议。您希望在初始开发过程中尽可能地建立一个健壮的核心数据模型。操作系统需要能够“升级”备份存储，以合并在核心数据模型修订之间所做的任何更改。如果您在初始设置核心数据模型方面做得很差，并且以这种方式发布代码，那么当应用程序处于运行状态时，尝试并进行复杂的模型更新可能会非常困难（正如您可能已经猜到的，这是一条来自痛苦经历的建议：）

+1回答一个不清楚的问题需要付出很大的努力。不过，我认为前两部分有点偏离了主题。关系不一定表示所有权——它们只表示两个数据段之间的某种连接。而且，你对继承的描述非常笼统；很难看出它是如何回答OP的问题的。@Caleb，谢谢你的建议。我觉得继承的概念并没有真正说明OP需要什么，所以为了完整性，我只对它进行了一般性的描述。我想确保我解决了问题中包含的所有主题。约定的关系不一定表示所有权，但因为这与问题更相关，所以我不想给出一个过于笼统的答案。这似乎是一个答案应该是“泛型”的细线。我认为你应该考虑添加一个“收据”实体。这样，您可以跟踪客户的购买情况，并根据过去购买的内容生成预算。