为我的iOS应用规划核心数据架构，我发现我有一些实体需要相同的属性集（例如描述性文本，评级，用户注释等）和关系（例如，用于申请）标签，附加参数，设置父/子关系，关联图像等）。对于一个实体“实体A”，共享属性/关系是它所需要的，而其他实体具有一些额外的唯一属性和/或关系。在这里阅读核心数据文档和帖子，我决定将“实体A”设置为其他人的父母。
一个额外的实体共享所有相同的属性和相同关系的子集，这是图像的实体（请注意，图像本身存储在文件中，此实体用于元数据并具有图像的键文件）。然而，“实体A”和儿童都需要与图像实体的多对多关系，而图像实体不需要与自身的关系。图像实体也不需要“实体A”的父/子关系。我看到了四种选择，但我无法确定要走哪条路。
我的问题是，这些选项中的任何一个是否具有我缺失的重要支持或者一个特定选项通常被认为是“正确”的做事方式。我已经读过，在Core Data中，所有子实体都将与父实体共享一个表，这可能导致大量对象的性能问题，但我预计我的应用程序最多只需要在这样的表中有几千行
选项1 ：将图片实体设置为“实体A”的子项，然后忽略它不需要的关系。这是最容易设置并充分利用继承，但我不知道忽略关系是否是一个很好的设计选择。 “实体A”具有我认为最容易以这种方式迁移的现有数据，但我也可以毫不费力地重新创建数据，因此这不是一个重要的考虑因素。没有当前的图像实体，因此不需要迁移它。
选项2 ：创建一个抽象父级，“实体A”和图像实体都是子级。父母将是“实体A”减去与图像的关系，“实体A”现在只与图像有关系。这似乎更清洁，目前我倾向于。虽然这看起来功能上很好，但从概念上讲，我不知道它是否适合具有基本元数据的实体作为父母。
选项3 ：创建一个单独的新“元数据”实体，即“实体A”减去图像关系，而不是抽象父项，并从两者中添加一个到元数据实体的一对一关系“实体A”和图像实体，就像制作复合对象一样。这似乎在概念上是合适的，因为元数据只是主要实体的一个方面，而不是定义因素（这是选项2的感觉）。它还将图像实体和“实体A”保存在单独的表中，并且应该允许通过元数据进行更有效的搜索。唯一的缺点，如果它是一个，就是它占据了“实体A”和图像实体的大多数属性和关系，并将它们作为一种关系加以处理。
选项4 ：忽略属性中的相似性，只是让图像实体完全分离，复制“实体A”中的所有属性。由于重复工作，这似乎是最不可取的。
答案 0 :(得分：2)
我最终选择了选项3（创建一个新的“元数据”实体），然后创建了两个独立的元数据子实体来处理“实体A”和图像实体的反向关系。就对象层次而言，这似乎是适当的行动方针。我还为“实体A”和图像实体添加了访问器，以方便传递元数据实体属性的调用。
由此产生的核心数据迁移需要一些步骤和一些自定义编码 - 可能比简单地创建一个空数据库并手动重新填充它更多，但这是一个很好的迁移学习经验。
完成迁移后，我确认了我读过的关于与父实体共享表的子实体的内容。在元数据实体的情况下，这意味着每行具有表示与“实体A”和图像实体的反向关系的列。作为参考，元数据表具有以下列：
Z_PK = row index
Z_ENT = entity index to distinguish between sub-entities (all entity indices are in the table Z_PRIMARYKEY)
Z_OPT = count of writes for the given row
Zxxxx - columns for each attribute and to-one relationship in the parent and sub-entities, apparently ordered with booleans first, then integers, then relationships, dates, and finally strings (from smallest to largest data size)
请注意，多个关系在不同的表中处理。