Données de base (SQLite/iPhone) - considérations de conception?

Question

Je suis en train de concevoir une application pour iPhone, en utilisant Core Data pour la persistance des données (avec le magasin SQLite local [s]). Avant d'aller trop loin dans la mise en œuvre, j'espère obtenir des conseils qualitatifs sur certaines questions de conception de base relatives aux données de base.

Voici le scénario:

• L'application gère les données sur des dizaines (voire des centaines) des étudiants - chacun avec plusieurs centaines d'articles individuels de données (chiffres et texte).

• La plupart du temps, l'utilisateur de l'application va accéder/modifier des informations sur un étudiant (à la fois). De temps en temps, ils reviennent à une vue de répertoire, qui montre une liste de tous les étudiants à choisir.

Alors, voici la première grande conception question:

BASE BOUTIQUES DE DONNÉES

Dans une telle application, quelle est l'approche la plus raisonnable de stocker toutes ces données: avec une seule banque de données, ou peut-être plusieurs magasins?

Approche # 1: Utiliserait UN magasin de données pour toutes les informations sur TOUS les étudiants.

Approche n ° 2: Utilisation de MULTIPLES magasins, un pour chaque étudiant. (Rappelez-vous qu'il existe des centaines d'éléments de données sur chacun d'entre eux.)

Approche n ° 3: Peut-être une approche hybride: plusieurs magasins, un pour chaque étudiant, avec un fichier 'index' séparé utilisé pour associer les métadonnées de base sur tous les étudiants avec le nom de fichier du magasin individuel de chaque étudiant.

~~~

- En supposant un instant, l'approche # 2: Cela signifie simplicité lors de l'accès aux données d'un élève. Cependant, afin de générer l'écran 'répertoire' qui répertorie tous les étudiants, je dois parcourir chaque magasin pour tabuler les informations nécessaires pour assembler cette liste (prénom, nom, et quelques autres éléments pour chaque personne - donc utiliser uniquement le nom de fichier de chaque magasin pour indiquer que les métadonnées ne sont pas suffisantes ou souhaitables).

Dans ce cas, je dois OUVRIR chacun des magasins, récupérer les métadonnées de base de l'étudiant, puis le refermer & passer au fichier suivant.

Est-ce inefficace? Est-il coûteux d'ouvrir/fermer potentiellement des douzaines (ou des centaines) de magasins individuels? [En fait, j'avais déjà commencé avec l'approche n ° 2, mais je me suis accroché en itérant dans plusieurs magasins pour créer cette vue "répertoire" - par conséquent, je me demande si c'est une approche raisonnable pour commencer avec.

Les considérations potentielles comprenaient: garder la taille de chaque fichier gérable; la conception de l'objet graphique un peu plus simple; et aussi pour minimiser le potentiel de perte de données si un magasin devait en quelque sorte devenir corrompu - mais je ne suis pas sûr de savoir à quel point cela est vraiment un problème pratique.]

DONNÉES DE BASE STACKS

- Ensuite, et l'approche en supposant à nouveau # 2: Comment faire en fait cela?

Pour ouvrir/lire/fermer un magasin particulier, devrais-je réutiliser un contexte singleton? ... Coordinateur? (c'est-à-dire, en premier lieu, Supprimer tout magasin ouvert de ce contexte, Ajouter le magasin suivant, et parcourir de cette manière?) Ou la version & reconstruire la pile pour chaque magasin que j'ai besoin de parcourir?

(Une considération possible serait d'éliminer le potentiel de commingling données entre les fichiers.)

Et qui de ces opérations sont coûteuses?

... Ou serait-il beaucoup plus simple d'utiliser un magasin de grande taille pour gérer toutes les données en premier lieu? : O

~~~

Quoi qu'il en soit, je me rends compte que c'est une question complexe, mais toute orientation serait très apprécié. Je souhaite également que cela aide d'autres personnes à utiliser les données de base pour leurs applications.

MERCI tellement à l'avance!

Answer 1

Des centaines d'étudiants avec des centaines d'éléments ne poseront généralement pas de problème pour un magasin de données sqlite3 CoreData, donc l'utilisation d'un seul magasin est parfaite. Vous voudrez probablement réfléchir aux champs que vous voulez indexés, mais à part ça, tout va bien. Dans tous les cas, l'ouverture et la fermeture de chaque magasin seront considérablement plus lentes que de tirer les données d'un seul magasin à ces échelles. Si vous trouvez vraiment que vous avez besoin de partager les données, il sera beaucoup plus complexe de le faire d'une manière raisonnable, et je ne chercherais pas à le traiter tant que vous n'obtiendrez pas les chiffres de performance qui vous disent. Ne vous inquiétez pas de gaspiller le travail de manière simple, puisque ce sera presque pas de travail comparé à une version fragmentée et vous permettra quand même de lancer l'application de base pour commencer à évaluer votre interface et tester la convivialité des applications.