CoreData：处理多态关联？
我不确定我在这里使用的术语是否正确，但假设我的模型中有四个实体：Person、Place、Tag 和<代码>照片。其他三个实体中的任何一个都可以有与之相关的Photo。有时人会拍摄照片并将其附加到标签、或地点，甚至另一个人代码>.在 CoreData 中处理多态关联的最佳方法是什么？
I'm not sure if I'm using the correct term here, but let's say I have four entities in my model: Person, Place, Tag, and Photo. Any of the other three entities can have a Photo related to it. Sometimes a Person will have taken the photo and will attach it to a Tag, or a Place, or even another Person. What is the best way to approach polymorphic associations in CoreData?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不建议像这样简单的事情继承实体。对于此设计，您有三个关系，
Person、Place和Tag中的每一个都与Photo 具有关系。 Photo`具有三个逆关系。它不需要比这更复杂。实体继承是一个非常微妙的工具，很容易给您带来许多问题。任何从另一个实体继承的实体都将被展平到一个表中。如果，正如 @morningstar 建议的那样，您创建了一个
Noun实体并让Person、Place和Tag继承自它，那么您SQLite 文件中将有 ONE 表，其索引指向其自身和其他内容。什么时候使用实体继承？
这是一个很难用简单规则来回答的问题。不过，我想说，基线是确保生成的表至少有 70% 的填充率。例如，如果您有一个包含 6 个属性的摘要和两个包含 2 个属性的子摘要，那么填充率可能约为 80%，并且可能没问题。
一般来说，我不使用实体继承，因为它几乎没有什么好处，而且对性能有很大的风险。旧规则有效，除非您知道需要使用它，否则不要使用它。
I do not recommend entity inheritance for something as simple as this. For this design you have three relationships, each of the
Person,PlaceandTaghave a relationship toPhoto.Photo` has three inverse relationships. It does not need to be any more complicated than that.Entity inheritance is a very delicate tool that can easily cause you many problems. Any entities that inherit from another will be flattened into a single table. If, as @morningstar suggested you created a
Nounentity and havePerson,PlaceandTaginherit from it you will have ONE table in the SQLite file with indexes pointing to itself and other nastiness.When to use entity inheritence?
That is a rather hard question to answer with a simple rule. However, I would say that a baseline would be to make sure that the resulting table has at least a 70% fill. For example, if you have an abstract with 6 attributes and two children with 2 attributes then that would probably be about an 80% fill rate and potentially ok.
In general, I do not use entity inheritence as it has little benefit and a great deal of risk to performance. The old rule works, don't use it unless you know you need to use it.
处理这个问题的另一种方法是创建 Photo 的子类，每个子类都有自己的一组关系。因此，您将创建 PersonPhoto、PlacePhoto 和 TagPhoto。这些实体中的每一个都将分别与人员、地点和标签具有适当的关系。所有常见功能和属性都存在于 Photo 中，但子类将关系分开。
这可能相当于在照片上创建所有这些关系，但我认为它更干净一些。
Another way of dealing with this is to create subclasses of Photo, each with their own set of relationships. So, you'd create PersonPhoto, PlacePhoto, and TagPhoto. Each of these entities would have the appropriate relationship with Person, Place, and Tag, respectively. All of the common functionality and attributes would live in Photo, but the subclasses keep the relationships separated.
This is probably equivalent to creating all of these relationships on Photo, but I think it's a little cleaner.
同意@mzarra。如果您的
Person、Place和Tag与Photo有关系，那么管理起来会更容易，并且您可以避免展平表索引问题。使用其他设计模式抽象出Person、Place和Tag之间的共同行为。在存储方面，您最终会在Photo上为您未使用的逆关系获得一些额外的未使用空间，但它平衡了实体继承中存储每个条目的类所浪费的存储空间。桌子。Agree with @mzarra. If you have
Person,PlaceandTaghave a relationship toPhotoit will be way easier to manage, and you avoid the flattened table indexing issues. Use other design pattern to abstract the common behaviors betweenPerson,PlaceandTag. On the storage side, you end up with some extra unused space onPhotofor the inverse relationships you are not using, but it balances the wasted storage you would have on entity inheritance storing the class for each entry on the table.使用实体继承。创建 Person、Place 和 Tag 的父实体。在这种情况下，父实体非常愚蠢。它没有属性。它不代表任何明确的对象类别。称其为“名词”是我能想到的最好的办法。
它具有一对多关系照片来键入照片。 Photo 与 Noun 类型具有反比关系 isPhotoOf。
Use entity inheritance. Make a parent entity of Person, Place, and Tag. In this case the parent entity is pretty stupid. It has no attributes. It doesn't represent any clear category of objects. Call it "Noun" is the best I can come up with.
It has a to-many relationship photos to type Photo. Photo has the inverse relationship isPhotoOf with type Noun.