CoreData:处理多态关联?

时间:2011-10-25 16:38:24

标签: iphone objective-c ios database-design core-data

我不确定我是否在这里使用了正确的术语,但我要说我的模型中有四个实体:PersonPlaceTag和{{ 1}}。其他三个实体中的任何一个都可以与Photo相关。有时,Photo会拍摄照片并将其附加到PersonTag或其他Place。在CoreData中处理多态关联的最佳方法是什么?

4 个答案:

答案 0 :(得分:7)

我不推荐像这样简单的实体继承。对于此设计,您有三种关系,PersonPlaceTag各自与Photo. Photo的关系有三种反向关系。它不需要比那更复杂。

实体继承是一种非常精密的工具,很容易导致许多问题。从另一个继承的任何实体将被展平为一个表。如果@morningstar建议您创建了Noun实体并且PersonPlaceTag继承了该实体,那么您将拥有 ONE 表格SQLite文件,索引指向自身和其他恶意。

何时使用实体继承?

用一个简单的规则回答这是一个相当难的问题。但是,我会说基线是确保结果表至少有70%的填充。例如,如果你有一个包含6个属性的抽象和两个具有2个属性的子项,那么这可能是大约80%的填充率并且可能没问题。

一般来说,我不使用实体继承,因为它几乎没有任何好处,也没有很大的性能风险。旧规则有效,除非您知道需要使用它,否则不要使用它。

答案 1 :(得分:0)

另一种解决方法是创建Photo的子类,每个子类都有自己的一组关系。因此,您可以创建PersonPhoto,PlacePhoto和TagPhoto。这些实体中的每一个都将分别与Person,Place和Tag具有适当的关系。所有常见的功能和属性都将存在于Photo中,但子类将关系分开。

这可能相当于在Photo上创建所有这些关系,但我认为它有点清洁。

答案 2 :(得分:0)

同意@mzarra。如果您有PersonPlaceTagPhoto有关系,那么管理起来会更容易,并且您可以避免扁平的表索引问题。使用其他设计模式来抽象PersonPlaceTag之间的常见行为。在存储方面,对于您未使用的反向关系,最终会在Photo上留出一些额外的未使用空间,但它会平衡您在实体继承上存储表中每个条目的类所浪费的存储空间。

答案 3 :(得分:-1)

使用实体继承。创建Person,Place和Tag的父实体。在这种情况下,父实体非常愚蠢。它没有属性。它不代表任何明确的对象类别。称之为“Noun”是我能想到的最好的。

它有一对多关系照片可以输入照片。照片具有与名称相反的isPhotoOf的反比关系。