Hi, all!
I’m in the process of designing an iPhone app, using Core Data for data persistence (with local SQLite store[s]). Before I get too far into the implementation, I’m hoping for some qualitative advice on some basic design questions relating to Core Data.
Here’s the scenario:
The app handles data on dozens (possibly hundreds) of Students -- EACH with several Hundred individual items of data (numbers and text).
Most of the time, the user of the app will be accessing/modifying information on one student (at a time).
Occasionally, they’ll pop back to a directory view, which shows a list of all students to choose from.
So here’s the first big design question:
CORE DATA STORES
In such an application, what’s the most reasonable approach to storing all this data: with a single data store, or perhaps multiple stores?
Approach #1: Would be using ONE data store for all the information on ALL the students.
Approach #2: Use of MULTIPLE stores, one for each student. (Remember that there’s hundreds of items of data on each and every one.)
Approach #3: Perhaps a hybrid approach: Multiple stores, one for each student, with a separate ‘index’ file used to associate basic metadata on all students with the filename of each student’s individual store.
~~~
-- Assuming for a moment, approach #2: This means simplicity when accessing a particular student’s data. However, in order to generate the ‘directory’ screen which lists all students, I’d need to iterate through each of the stores to tabulate the information needed to assemble that list (first name, last name, and a few other items for each person -- so using just each store's filename to represent that metadata isn’t sufficient, or desirable).
In this case, I’d need to OPEN each of the stores, retrieve the student’s basic metadata, then close it up again & move to the next file.
Is this inefficient? Is it expensive to open/close potentially dozens (or hundreds) of individual stores?
[In fact, I’d already started in with approach #2, but have gotten hung up in iterating across multiple stores to create that ‘directory’ view -- hence, I’m wondering if it’s a reasonable approach to begin with.
The potential considerations included: keeping the size of each file manageable; the design of the object graph a little simpler; and also to minimize the potential for data loss if a store should somehow become corrupt -- but I’m not sure how much of a practical issue that really is.]
CORE DATA STACKS
-- Next, and again assuming approach #2: How to actually do that?
To open/read/close a particular store, should I reuse a singleton Context? ... Coordinator? (i.e., first, Remove any opened store from that Context, Add the next store, and iterate through that way?) Or release & reconstruct the stack for each store I need to iterate through?
(One possible consideration would be to eliminate the potential of commingling data between files.)
And which of these operations are expensive?
... Or would it much simpler just to use one large-ish store to handle all data in the first place? :O
~~~
Anyway, I realize this is an elaborate question, but any guidance would be VERY much appreciated.
I also hope this helps others using Core Data for their apps as well.
THANK YOU so much in advance!