假设您需要使用一个实体构建一个应用程序，该实体可以与多种其他类型的实体相关联。例如，您有一个 Picture 实体，它可以与 Meal 实体、Person 实体、Boardroom 实体、Furniture 实体等相关联。我可以想出许多不同的方法来解决这个问题，但是——也许是因为我是 Core Data 的新手——我对它们中的任何一个都不满意。
想到的最明显的方法是简单地在 Picture 和支持关联图片的每个实体之间创建关系，但这看起来很草率，因为图片将有多个“空指针”。
另一种可能性是创造一个 super 实体——可想象的——或其他东西。每个支持关联图片的实体都是 Pictureable 的子实体，而 Picture 本身将与 Pictureable 一对一。我发现这种方法很麻烦，因为它不能在一个项目的上下文中使用多次(因为 Core Data 不支持多重继承)以及 Core Data 似乎为任何给定的根实体创建一个表的方式——假设SQLite 支持——让我害怕将一大堆不同的子实体分组到一个共同的 super 实体的保护伞下(我意识到沿着这些思路思考可能有点过早优化的味道，所以如果我是个笨蛋请告诉我)。
第三种方法是为图片创建一个由“类型”和“UID”组成的组合键。假设我的数据模型中的每个实体都有一个 UID，我可以使用这个键从 Picture 实例派生一个关联的托管对象，反之亦然。这种方法让我很担心，因为它听起来在大量获取时可能会变得慢；它对我来说也不够原生。
第四种方法——我在我正在开发的应用程序中倾向于采用的方法——是为图片和 X(其中 X 是膳食、人员、 session 室等)创建子实体，并创建一个这两个子实体之间是一对一的。虽然这种方法似乎是百害而无一利，但对于我未经训练的人来说，它仍然显得深奥，所以我想知道是否有更好的方法。
编辑 1:在最后一段中，我的意思是说我倾向于为图片创建子实体只是，不是图片和 X。
最佳答案
我认为这个主题的最佳变体是(不一定按顺序):
为与 Meal、Person、Boardroom 等相关联的图片使用单独的实体。这些实体可能都具有相同的属性，而且它们实际上可能都使用相同的类实现。这并没有错，而且它使得在每种实体和存储其图片的实体之间建立双向关系变得简单。
使图片成为每个实体类型的属性，而不是单独的实体。如果将实际图片数据存储在数据库中，就效率而言，这不是一个好计划，但如果将图像存储为单独的文件并将该文件的路径存储在属性中，那就没问题了。如果图片或记录数较少，即使将图片数据存储在数据库中也可能不是问题。
对所有图片使用单个实体，但省略与关联实体的反向关系。有一个 helpful SO question 考虑了这一点，并且接受的答案链接到文档的更有用的 Unidirectional Relationships 部分。如果您不需要 picture->owner 关系，这可能是解决您的问题的一个很好的解决方案，但您应该在走这条路之前了解可能的风险。
如您在列出的第一个选项中所述，为每种可能的所有者提供您的图片实体单独的关系。如果您需要能够作为一个组访问所有图片并且需要从图片到其所有者的关系，并且如果可能的所有者实体的数量相对较少，这可能是您的最佳选择，即使它拥有空属性似乎很草率。
正如您所注意到的，当您对实体使用继承时， all the sub-entities end up together in one big table 。因此，您的第四个选项(为每种图片使用子实体)在本质上与您的第一个选项类似。
更多地考虑这个问题，我倾向于使用实体继承来为与每种类型的所有者实体关联的图片创建子实体。 Picture 实体将只存储与任何图片关联的数据。每个子实体，如 MealPicture 和 PersonPicture，都会为其自己的特定类型的所有者添加关系。通过这种方式，您可以获得双向 Meal<->MealPicture 和 Person<->PersonPicture 关系，并且因为每个子实体都继承了所有常见的 Picture 内容，所以您避免了困扰您的 DRY 违规。简而言之，您可以获得上面选项 1 和 3 的大部分最佳部分。在底层，Core Data 像上面的选项 4 一样管理图片，但在使用中每个图片子实体只公开一个关系。
关于objective-c - 一个架构师如何在 Core Data 中创建具有通用关系的实体？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6615591/