核心数据性能是否更好，属性更少？

我有一个名为DiveSite的核心数据实体，它具有大量属性，其中很多属性代表影响潜水站点的功能或条件的布尔值。核心数据性能是否更好，属性更少？

其实，我有这么多的属性，即Xcode中给了我一个警告 - “配置错误的实体 - DiveSite拥有超过100种性能;考虑更浅的实体层次或反规范化属性”

许多属性可能是分组减少了实体上属性的总数 - 我可能会将布尔变量组变成一系列整数，并进行逻辑并检查我想要的因素。

我也意识到，我可以让这些组分为单独的实体 - 其中一些将有1-1的关系和一些1-多关系

在性能方面会改变我的DiveSite实体少属性是一件积极的事情吗？

如果是这样，那么可能会有更好的性能明智的拥有单独的实体，或者可能有6个属性，我使用谓词来过滤。？

考虑这个问题时，我意识到，如果我走单独的实体路线，我允许自己添加因子，只需将它们添加为实体的实例而不更改我的代码。

在我写这篇但希望体验的核心数据的意见/和数据库用户那里

干杯

来源

2013-07-30 SimonTheDiver

是它的劝，让您的实体小我可能已经回答了我的问题。例如，当您有一个列表视图时，您通常不需要关于对象的所有信息，但是当您单击一个并转到详细信息视图时，您需要获取更详细的信息。然后你可以从其他实体中获取它。

当然，你应该在这些实体之间建立关系。

来源

2013-07-30 10:57:41 rednaw

那么，当你获取一个实体时，所有的属性都与它一起被填充？ – user523234

是的，它提取整个实体。 – rednaw

我认为情况有点复杂。核心数据获取所有属性值（如果'includesPropertyValues'为'YES'，则默认为），并将它们存储在行缓存中。托管对象将作为错误返回，并且稍后将使用行缓存中的值填充。您可以通过将'returnsObjectsAsFaults'设置为'NO'来更改此行为。也就是说，分割你的实体听起来像个好主意。 –

我不能说这是一个很好的做法，以保持实体“小”与否。但是根据我对核心数据的经验，大实体不是问题。

大，我的意思是一个具有25到50个属性的实体，例如很多长字符串或二进制数据。对于该大小的实体，查询时间通常大于加载和实例化时间。在一次获取中获取1000个完整实体通常比获取1000个部分实体要快，然后错过100个缺失属性。

在附注中，我必须在运输产品中添加我很少使用的那种尺寸的实体。大型实体几乎总是在几个较小的相关实体中重构。

现在你告诉你达到了100个属性。哇。我认为我从来没有在我的任何项目中达到过这个标准 - 核心数据或任何“经典”数据库。我会说这里的第一个问题是可读性&可维护性。我很肯定你可以重构一个小实体的大实体，定义定义主体实体的核心属性，在这里或那里找到一些共享的值等等。这肯定会有帮助。

与往常一样，性能上的明智之处在于，剖析器能准确测量时间花在哪里。根据我的经验，提取太多会发生，但提取太少（也就是大量查询）。

来源

2013-07-31 21:40:29

核心数据性能是否更好，属性更少？

回答

相关问题