我有一个名为 DiveSite 的核心数据实体，它具有大量属性，其中许多是表示影响潜水地点的特征或条件的布尔值。
事实上，我有很多属性，xCode 给了我一个警告 - “错误配置的实体 - DiveSite 有 100 多个属性；考虑更浅的实体层次结构或非规范化属性”
这些属性中的许多可以分组以减少实体上的属性总数 - 我可以将布尔值组更改为一系列整数并进行逻辑检查并检查我想要的因素。
我也意识到我可以将这些组变成单独的实体——其中一些将具有 1-1 关系，一些将具有 1-many 关系
就性能而言，将我的 DiveSite 实体更改为具有更少的属性是一件积极的事情吗？
如果是这样的话，拥有单独的实体或拥有我称之为使用谓词进行过滤的 6 个属性可能会在性能方面更好。?
在提出这个问题时考虑到这一点，我意识到如果我采用单独的实体路线，我允许自己将因素添加到某些实体中，只需将它们添加为实体的实例而不更改我的代码。
在我写这篇文章时，我可能已经回答了我自己的问题，但我会很感激经验核心数据/和数据库用户的意见
干杯
是的，建议保持您的实体很小。例如，当您有一个列表视图时，您通常不需要对象的所有信息，但是当您单击一个并转到详细视图时，您会想要获取更详细的信息。然后您可以从其他实体中获取它。
当然，您应该在这些实体之间建立关系。
我不能说保持实体“小”是否是一个好习惯。但根据我对 Core Data 的经验，大型实体不是问题。
所谓大，是指具有 25 到 50 个属性的实体，例如有很多长字符串或二进制数据。对于这种大小的实体，查询时间通常大于加载和实例化时间。一次获取 1000 个完整实体通常比获取 1000 个部分实体然后出错 100 个缺失属性更快。
附带说明一下，我必须在运输产品中添加我很少使用的那种尺寸的实体。大型实体几乎总是在几个较小的相关实体中重构。
现在你告诉你达到了大约 100 个属性。哇。我想我从来没有在我的任何项目中达到这个目标——Core Data 或任何“经典”数据库。我想说这里的第一个问题是可读性和可维护性。我很确定您可以将这么大的实体重构为较小的实体，定义定义主体实体的核心属性，在这里和那里找到一些共享值等等。这肯定会有所帮助。
与往常一样，性能方面的答案在于分析器，以准确测量花费时间的位置。根据我的经验，获取太多会发生，但获取太少（也就是查询负载）会更频繁地发生。