【问题标题】:Core Data multiple instances of same Entity - entities that share attributesCore Data 同一实体的多个实例 - 共享属性的实体
【发布时间】:2015-05-25 00:19:16
【问题描述】:

我正在努力思考如何拥有同一个 Core Data 实体的多个实例。这似乎不可能,所以我一定是在接近这个错误。

基本上,假设我有一个可以装满多个气球的购物车。但是每个气球可以有不同的颜色。如果我编辑气球的模板,所有气球都会更新以反映更改。所以假设我将模板的名称更改为“培根”,所有气球的名称也会更改为“培根”。

我将如何使用 Core Data 实现这一目标?

编辑

根据要求,我将尝试澄清我正在尝试做的事情。

也许这个例子会更清楚。

假设您正在创建一个练习模型。所以你有Ab RollerShoulder Press等。

workout 中,您可能有多个实例。因此,在一个 workout 中,您将拥有,说

  1. Ab Roller
  2. Shoulder Press
  3. Ab Roller

Ab Roller 的每个实例都将与 Sets 有自己的关系,这对于每个课程来说都是不同的。

也许不是最好的例子,但应该可以更清楚地理解重复实例。

我在考虑拥有一个template 实体,然后是一个instance 实体,以及它们之间的关系——当template 实体name 更新时,所有instance 实体的name 都通过KVO 更新.或者我将所有共享属性(即name)放在关系中(因此instance 实体的name 属性返回其templatename 属性),以便它们反映对template 的更改.最好的方法是什么?

【问题讨论】:

  • 你能说明你想要达到什么目标吗?让所有气球同步它们的属性?还是相反?顺便说一句,当您提到“模板”时,您是什么意思?你能提供一些代码来突出不需要的行为吗?
  • 如果我理解正确,这不是核心数据问题,而是数据库设计决策。如果你想让气球组共享一些属性——比如模板,你可以在数据库中创建新实体——ballon_template,多个气球将使用相同的模板。然后更改模板会更改多个气球。基本上你想使用关系。
  • 我同意这更像是一个一般性的数据库问题,因为我没有过去 Core Data 构建数据模型的经验。我编辑了另一个我想要了解的示例,这有帮助吗?
  • 你可以按照你最后说的做,把访问器改写成你想要的对象的名字,返回模板中存储的名字。所有对象都需要与模板有关系,并且模板必须是唯一的。
  • 我将如何处理这些关系?假设template 与身体部位有关系。当访问instance 以获取正文部分时,说instance.template.bodypart 似乎很乱。我更喜欢instance.bodypart,这将返回来自template 的关系。还是我应该在instance 上写一个方便的方法并且不设置任何关系?

标签: ios entity-framework core-data database-design data-modeling


【解决方案1】:

我将从数据库设计的角度来回答这个问题,因为 cmets 一致认为这更像是一个通用的数据库设计问题。如果这不能解决您的所有问题,那么希望了解 Core Data 来龙去脉的人可以为您解决这方面的问题。

您正在考虑为您的系统保存一些配置数据,然后还为使用该配置数据的实体的各种实例保存数据。您提出的具有模板实体(我也见过这称为定义或配置实体)和实例实体的一般模式肯定是我以前遇到过的,我没有看到问题用那个。

数据库规范化规则告诉您避免数据库中的数据复制。因此,如果您的模板实体有一个名称字段,并且每个实例实体都应该具有相同的名称,那么您应该将名称留在模板实体中并通过外键引用该实体。否则,当名称更改时,您必须更新实例表中的每一行以匹配 - 这将是一项昂贵的操作。或者更糟糕的是,它没有得到更新,最终导致系统中的数据不匹配 - 这被称为update anomaly

因此,为某种电子商务解决方案(就像您的第一个示例一样)考虑购物车和库存的想法,您可能有一个 BasketItem 实体和一个 ItemTemplate 实体:

ItemTemplate:  
* ItemTemplateId  
* Name  

BasketItem:  
* BasketItemId  
* ItemTemplateId  
* Color

然后您的气球模板数据和气球实例的数据在数据库中将如下所示:

项目模板:

| ItemTemplateId | Name    |  
| 7              | Balloon |  

篮子项目:

| BasketItemId | ItemTemplateId | Color   |  
| 582          | 7              | Blue    |  
| 583          | 7              | Green   |

(这显然被大大简化了,只看一个具体的例子,而忽略了篮子和物品的所有机制,所以不要把它当作实际的设计建议。)

此外,您可能希望保存更多配置数据,这可能会彻底改变设计:例如,您可能希望保存有关不同产品可用颜色的配置数据。上面使用的相同概念适用于其他地方——如果你意识到你一遍又一遍地拿着“蓝色”,并意识到你将来可能想把它改成“深蓝色”,因为你现在储存了多种颜色的蓝色气球,那么这是有道理的让颜色只存储一次,然后有一个外键指向它的存储位置,这样您就不会对整个 BasketItem 表进行大规模更新以将“蓝色”的每个实例更新为“深蓝色”。 "


我强烈建议您阅读一些有关数据库设计和数据库规范化的内容。这将有助于回答您在这些方面的任何问题。你可能会发现在某些情况下你需要打破规范化规则——也许是为了让 ORM 工具能够优雅地工作,或者出于性能原因——但最好以明智的方式做出这些决定,知道你可能会导致什么问题并且采取进一步措施防止它们发生。

【讨论】:

  • 这很棒。我最终实际上这样做了。使用真实项目上的属性来访问名称等模板项目。你能澄清一下and then have a foreign key pointed to wherever it is stored, so that you're not carrying out a massive update to your entire BasketItem table to update every instance of "Blue" to "Dark blue 的意思吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-05-26
相关资源
最近更新 更多