3

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

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

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

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

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

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

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

4

1 回答 1

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)

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

于 2013-02-23T23:59:08.627 回答