title: Cocoa Touch: When does an NSFetchedResultsController become necessary to manage a Core Data fetch?
body: <p>I'm developing an iPhone application that makes heavy use of Core Data, primarily for its database-like features (such as the ability to set a sort order or predicate on fetch requests). I'm presenting all the data I fetch in various UITableViewControllers.</p>
  
  <p>What I'd like to know is a rough idea of how many objects I can fetch before it becomes a good idea to use an NSFetchedResultsController  to handle the request. In the Core Data docs, it says that SQLite stores consider "10,000 objects to be a fairly small data set," but in the documentation for NSFetchedResultsController it mentions keeping "tens of objects" in memory at a time.</p>
  
  <p>I'm dealing primarily with data sets of up to fifty objects that each have maybe a dozen instances of NSNumber and NSString, as well as a one-to-many relationship for the next set of objects (i.e. there are twenty instances of object A, each of which have a to-many relationship to a set of thirty (distinct) instances of object B, each of which...).</p>
  
  <p>Is this scenario a good fit for using an NSFetchedResultsController, or can I get away with a simple NSArray of results? I don't have an issue with managing the niceties of the controller (convenience methods to get an object for a UITableView index path, adding new objects back to the context, etc.) myself, I'm just wondering about the memory usage of each approach.</p>
  
  <p>I should mention the app will be targeted primarily at iPhone 3G (not S) and first-gen iPod Touch users, so please keep the limited memory of these platforms in mind.</p>