增强我的核心数据设计。仅限专家！
在AcaniUsers，我正在下载距离我最近的 20 个用户，并在表格视图中将他们的个人资料图片显示为缩略图。用户&照片都是资源，因为它们在服务器上都有一个 id (MongoDB BSON ObjectId)。每个用户都有一个唯一的_id。每张照片在服务器上都有四种不同的尺寸（图像）：方形：75x75、方形@2x：150x150、大：320x480、大@2x：640x960。但是，每台设备只有其中两种尺寸，具体取决于它是 iPhone 3 还是 4（视网膜显示屏）。每个大小都有自己的 MongoDB 集合。而且，每张照片的所有四张图像在这四个集合中都具有相同的 BSON ObjectId。
将来，我可能会给用户一个名为 photos 的关系，以允许用户拥有多张照片。另外，虽然我没有预见到这一点，但我可能会添加更多图像尺寸（类型）。
Image 上的 fresh 属性告诉我是否已经下载了最新的图像。每当照片的ID发生更改时，我都会将其设置为NO，然后在下载完图像后恢复为yes。
我应该将四个不同的图像存储在 Core Data 中还是文件系统上，而只将它们的 URL 存储在 Core Data 中？我在某处读到超过 1 或 2MB 的数据应该存储在文件系统中，而不是核心数据中。因此，我正在考虑将方形图像存储在 Core Data 中，将大图像存储在文件系统中，但我宁愿以相同的方式存储它们，以使事情变得更容易。那么，也许我会将它们全部存储在文件系统中？您觉得怎么样？
你认为我应该放弃 75x75 和 75x75 吗？ 320x480 尺寸，因为 iPhone 3 很快就会消失？
如何改进实体及其属性和关系的设计。例如，资源实体到底有没有用？
我正在使用 NSFetchedResultsController 显示用户。但是，它不知道用户的图像何时更新，因此直到我第一次积极滚动时图像才会显示。如何让 NSFetchedResultsController 知道用户的缩略图已完成下载？我必须使用 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.
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?
Do you think I should discard the 75x75 & 320x480 sizes since pretty soon iPhone 3's will be gone?
How can I improve my design of the entities, and their attributes and relationships. For example, is the Resource entity even beneficial at all?
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
回答你的问题：
1 我将它们全部存储在文件系统中，并将 URL 记录在数据库中。我从来都不热衷于在数据库中存储图像数据。另外，它会稍微简化一些事情，使所有图像存储统一。这样，在图像加载代码中，您不必担心它是存储在数据库中还是文件系统中的类型。
2 不，我还不会那么做。 iPhone 3 的存在时间将会更长一些。 ATT 仍将它们作为廉价入门级 iPhone 进行销售。前几天晚上我刚看到一则广告，广告价为 49 美元。
3 删除资源条目并将 id 属性添加到每个类。你的做法实际上很糟糕。仅当您有几个几乎相同且之间只有一些差异的实体时，才应使用抽象实体。在底层，Core Data 只会为抽象实体及其所有子实体创建一张表。因此，现在您最终将只有一张表，其中包含您的用户和照片条目，当您尝试仅查询实体类型时，这可能会很糟糕。
您还应该删除“图像”实体并将其属性移至“照片”实体中。照片将始终具有与其关联的这些值，并且照片之间不会共享相同的值。将它们作为一个单独的实体会导致速度变慢。您要么需要使用需要连接的照片来加载它们（速度很慢），要么当您访问数据或新属性时一次加载一张照片，这也很慢。当在后一种情况下触发每个故障时，每个对象都会发生单独的查询和磁盘往返。因此，当您循环遍历图片以在表中显示时，您将触发 n 个查询，而不是一个，这可能会导致性能上的巨大差异。
4 可以使用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.