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