core-data - 核心数据子实体与具有相似属性的实体的关系

Question

为我的 iOS 应用程序规划核心数据架构时，我发现我有一些实体需要相同的属性集(例如描述性文本、评级、用户注释等)和关系(例如应用标签、附加参数、设置父/子关系、关联图像等)。对于一个实体“实体 A”，共享的属性/关系是它所需要的，而其他每个实体都有一些额外的独特属性和/或关系。阅读核心数据文档和此处的帖子，我决定将“实体 A”设置为其他实体的父级。

一个额外的实体共享所有相同的属性和相同关系的一个子集，那就是图像的实体(注意图像本身存储在文件中，这个实体是元数据并且有一个图像的键文件)。然而，“实体 A”和子实体都需要与图像实体建立一对多关系，而图像实体不需要与自身建立关系。图像实体也不需要“实体 A”的父/子关系。我看到四个选项，但无法确定要走哪条路。

我的问题是这些选项中的任何一个是否具有我遗漏的重要优点或缺点，或者某个特定选项是否通常被认为是“正确”的做事方式。我读到在 Core Data 中所有子实体将与父实体共享一个表，这可能会导致大量对象的性能问题，但我预计我的应用程序最多只需要在这样的表中有几千行.

选项 1:将图像实体设置为“实体 A”的子实体，并忽略它不需要的关系。这是最容易设置并充分利用继承的优势，但我不知道忽略关系是否是一个好的设计选择。 “实体 A”拥有我认为最容易以这种方式迁移的现有数据，但我也可以毫不费力地重新创建数据，因此这不是一个重要的考虑因素。当前没有图像实体，因此迁移不是问题。

选项 2:创建“实体 A”和图像实体都是其子项的抽象父项。父项将是“实体 A”减去与图像的关系，“实体 A”现在只与图像有关系。这看起来更干净，目前是我所倾向的地方。虽然这在功能上看起来不错，但从概念上讲，我不知道将本质上是元数据的实体作为父实体是否合适。

选项 3:代替抽象父级，创建一个单独的新“元数据”实体，即“实体 A”减去图像关系，并向来自两者的元数据实体添加一对一关系“实体A”和图像实体，就像在制作一个合成对象。这在概念上似乎是合适的，因为元数据只是主要实体的一个方面，而不是定义因素(这是选项 2 的感觉)。它还将图像实体和“实体 A”保存在单独的表中，并且应该允许更有效地通过元数据进行搜索。唯一的缺点(如果有的话)是它获取了“实体 A”和图像实体的大部分属性和关系，并将它们作为关系添加。

选项 4:忽略属性的相似性，只使图像实体完全分离，复制“实体 A”的所有属性。由于重复工作，这似乎是最不可取的。

Answer 1

我最终选择了选项 3(创建一个新的“元数据”实体)，然后创建了两个独立的元数据子实体来处理“实体 A”和图像实体的反向关系。就对象层次结构而言，这似乎是合适的做法。我还向“实体 A”和图像实体添加了访问器，以便于传递对元数据实体属性的调用。

由此产生的 Core Data 迁移需要几个步骤和一些自定义编码——可能比简单地创建一个空数据库并手动重新填充它需要更多的工作，但这是一个很好的迁移学习体验。

完成迁移后，我确认了我所读到的关于子实体与父实体共享一个表的内容。在元数据实体的情况下，这意味着每一行都有代表与“实体 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)

请注意，对多关系在单独的表中处理。