增强我的核心数据设计。专家！ [英] Enhance my Core Data design. Experts only!

问题描述

a href =https://github.com/acani/AcaniUsers =nofollow noreferrer> AcaniUsers ，我正在下载最接近的20个用户，并在表视图中将他们的个人资料图片显示为缩略图。用户&照片都是资源，因为它们在服务器上都有一个 id （MongoDB BSON ObjectId）。每个用户都有一个unique_id。每张照片在服务器上有四种不同大小（图像）：正方形：75x75，正方形@ 2x：150x150，大：320x480，大@ 2x：640x960。但是，每个设备只有这两个尺寸，取决于它是一个iPhone 3或4（视网膜显示屏）。每个这些大小都有自己的MongoDB集合。

在未来，我可以给用户一个名为的关系，照片，以允许用户拥有多张照片。

新鲜虽然我不预见这一点，属性图像告诉我是否已下载最新的图像。每当照片的I​​D已更改时，我将此设置为 NO ，然后在完成后返回yes下载图片。

1. 我应该将四个不同的图片存储在Core Data或文件系统中，核心数据？我读的地方，超过1或2MB，你应该存储在文件系统，而不是核心数据。所以，我正在考虑将方形图像存储在Core Data和文件系统中的大图像，但我宁愿存储它们都一样，以使事情更容易。所以，也许我只是将它们都存储在文件系统中？




2. 你认为我应该丢弃75x75，




3. 如何改进我的实体设计，以及它们的属性和关系。例如，资源实体是否甚至有益？




4. 我使用NSFetchedResultsController显示用户。但是，它不知道用户的图像何时更新，所以图像不显示，直到我第一次积极滚动。如何让NSFetchedResultsController知道用户的缩略图已完成下载？

解决方案

要回答您的问题： / p>

1我将它们全部存储在文件系统中，并在数据库中记录URL。我从来没有把图像数据存储在DB中的大粉丝。此外，它会简化一些事情，让所有的图像存储统一。这样，在你的图片加载代码中，你不必担心它是存储在DB还是文件系统上的类型。

2不，我不会还没有。 iPhone 3将在周围有一段时间。 ATT仍然将它们作为便宜的入门级iPhone销售。我刚看到一个商业广告，另一个晚上广告他们为$ 49。

3删除Resources条目并向每个类添加id属性。你怎么做的实际上是坏的。抽象实体应该只在你有几个实体几乎相同，并且它们之间只有一些差异时才使用。在引擎盖下，Core Data将只为抽象实体和其所有子项创建一个表。所以现在你将最终只有一个表，将包含您的用户和照片条目，当你试图查询只是类型的实体可能是坏的。

您还应该删除Image实体并将其属性移动到Photo实体中。照片将始终具有与其相关联的那些值，并且相同的值不会在照片之间共享。将它们作为一个单独的实体将导致减速。你需要加载他们需要加入（慢）的照片，或者当你访问数据或新的属性也很慢，它们将被加载一个。当在后一种情况下触发每个故障时，对于每个对象将发生对磁盘的单独查询和往返行程。因此，当您循环显示图片以在表格中显示时，您会发出n个查询，而不是一个可能会在性能上有很大差异的查询。

4您可以使用KVO来做。让您的表格单元格观察者为用户或图片（取决于您是否已将图片添加到用户并正在更改数据，或者如果您在加载完成时向用户添加新图片）。当观察者被触发时，更新正在显示的图像。

In AcaniUsers, I'm downloading the closest 20 users to me and displaying their profile pictures as thumbnails in a table view. User & Photo are both Resources because they each have an id (MongoDB BSON ObjectId) on the server. Each user has a unique_id. Each Photo has four different sizes (images) on the server: square: 75x75, square@2x: 150x150, large: 320x480, large@2x: 640x960. But, each device will only have two of these sizes, depending on whether it's an iPhone 3 or 4 (retina display). Each of these sizes has their own MongoDB collection. And, all four images for each Photo have the same BSON ObjectId's across these four collections.

In the future, I may give User a relationship called photos to allow a user to have more than one photo. Also, although I don't foresee this, I may add more Image sizes (types).

The fresh attribute on Image tells me whether I've downloaded the latest Image. I set this to NO whenever the Photo's ID has changed, and then back to yes after I've finished downloading the Image.

1. Should I store the four different images in Core Data or on the file system and just store their URLs in Core Data? I read somewhere that over 1 or 2MB, you should store in file system, not Core Data. So, I was thinking of storing the square images in Core Data and the large images in the file system, but I'd rather store them all the same way to make things easier. So, maybe I'll just store them all in the file system? What do you think?

2. Do you think I should discard the 75x75 & 320x480 sizes since pretty soon iPhone 3's will be gone?

3. How can I improve my design of the entities, and their attributes and relationships. For example, is the Resource entity even beneficial at all?

4. I'm displaying the Users with an NSFetchedResultsController. However, it doesn't know when the User's image gets updated, so the images don't show up until I scroll aggressively the first time. How do I let the NSFetchedResultsController know that a user's thumbnail has finished downloading? Do I have to use KVO?

解决方案

To answer your questions:

1 I'd store them all in the file system and record the URL in the database. I've never been a big fan of storing image data in the DB. Plus it'll simplify things a little to have all of the image storage uniform. That way in your image loading code you don't have to worry about if it's a type that's stored in the DB or on the file system.

2 No, I wouldn't do that yet. The iPhone 3 is going to be around for a bit longer. ATT is still selling them as the cheap entry level iPhone. I just saw a commercial the other night advertising them for $49.

3 Remove the Resources entry and add the id attribute to each of the classes. How you did it is actually bad. Abstract entities should only be used when you have a couple of entities that are almost identical and only have a few differences between them. Under the hood, Core Data will make only one table for an abstract entity and all of its children. So right now you're going to end up with only one table that will contain both your user and photo entries which can be bad when you're trying to query just type of entity.

You should also delete the Image entity and move its attributes into the Photo entity. The Photo will always have those values associated with it and the same values won't be shared between photos. Having them as a separate entity will cause a slow down. You'll either need to load them with the photos which will require a join (slow) or they'll be loaded one at a time when you access either the data or fresh attributes which is also slow. When each of the faults is fired in the latter scenario a separate query and round trip to the disk will happen for each object. So when you loop through your pictures for display in the table, you'll be firing n queries instead of one which can be a big difference in performance.

4 You can use KVO to do it. Have your table cell observer the User or Picture (depends on if you have the Picture already added to the user and are changing the data or if you're adding a new picture to the user on load completion). When the observer gets triggered, update the image being displayed.

这篇关于增强我的核心数据设计。专家！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！