Comment stocker de nombreux drapeaux d'articles dans les données de base

Question

J'essaie de faire ce qui suit dans mon application iPad. J'ai une structure qui permet aux gens de créer des listes groupées que nous appelons "Templates". Donc, le niveau supérieur CoreOffer (a Titre) qui peut avoir de nombreux groupes (a grouptitle/displayorder) qui peut avoir beaucoup d'éléments (a ItemTitle, DisplayOrder). Comme indiqué ci-dessous. Cela fonctionne très bien, je peux créer des modèles parfaitement.

lien image http://img405.imageshack.us/img405/9145/screenshot20110610at132.png

Mais une fois Les modèles sont créés les gens que peuvent les utiliser pour la carte contre le modèle que je vais appeler une évaluation. Un modèle peut être utilisé plusieurs fois. L'évaluation contiendra une date (système généré) et les éléments de ce modèle particulier ont été sélectionnés.

Exemple ci-dessous, les gens pourront vérifier des lignes particulières dans l'écran ci-dessous, ceci est alors une évaluation.

lien image http://img41.imageshack.us/img41/8049/screenshot20110610at133.png

Je me bats pour comprendre comment créer et stocker ces informations dans le modèle de données de base sans dupliquer le modèle. (Difficulté venant d'un fond de SQL!) En SQL cela impliquerait quelque chose comme une table d'évaluation enregistrant chaque itemid et son statut de sélection.

Je m'attends à ce qu'il soit assez simple, mais je ne peux pas me tromper!

Merci

Answer 1

La première chose que vous voulez faire est de nettoyer la dénomination de votre modèle de données. Souvenez-vous que vous avez ici affaire à des objets uniques et non aux noms de tables, de colonnes, de lignes, de jointures, etc. dans SQL. Ainsi, vous n'avez pas besoin de tout préfixer avec "Core" (sauf si vous avez plusieurs types d'entités Offer, Group et Item.)

Les noms d'entités commencent par des majuscules, des noms d'attributs et des relations avec des minuscules. Tous les noms d'entités sont singuliers parce que la modélisation de l'entité ne dépend pas du nombre d'instances de l'entité ou du type de relation qu'elle aura. Les noms de relation à un doivent être singuliers et pluriels. Ces conventions rendent le code facile à lire et à transmettre des informations sur le modèle de données sans avoir à voir le graphique réel.

Donc, nous pourrions nettoyer votre modèle existant comme:

Offer{ 
    id:string 
    title:string 
    groups<-->>Group.offer 
} 

Group{ 
    title:string 
    displayOrder:number 
    offer<<-->Offer.groups 
    items<-->>Item.group 
} 

Item{ 
    title:string 
    displayOrder:number 
    isSelected:Bool 
    group<<-->Group.items 
} 

Maintenant, si vous lisez un keypath dans le code qui va AnOfferObj.groups.items vous pouvez instantanément vous dire traversons deux à àplusieurs sans savoir quoi que ce soit d'autre au sujet le modèle de données.

Je ne sais pas exactement ce que vous voulez que vos "évaluations" à "copier". Vous semblez soit vouloir les "copier" le graphique entier de tout Offer ou vous voulez les "copier" un ensemble d'objets Item. Dans les deux cas, la solution consiste à créer une entité Evaluation pouvant établir une relation avec Offer ou Item.

Dans le premier cas, il ressemblerait à ceci:

Evaluation{ 
    title:string 
    offer<<-->Offer.evaluations 
} 

Offer{ 
    id:string 
    title:string 
    groups<-->>Group.offer 
    evaluations<-->>Evaluation.offer 
} 

...et dans le second cas:

Evaluation{ 
    title:string 
    items<<-->>Item.evaluations 
} 

Item{ 
    title:string 
    displayOrder:number 
    isSelected:Bool 
    group<<-->Group.items 
    evaluations<<-->>Evaluation.items 
} 

Notez que dans aucun des deux cas vous ne dupliquez ou ne copiez quoi que ce soit. Vous créez simplement une référence à un groupe d'objets existant. Dans le premier cas, vous trouverez tous les objets Item associés pour un objet particulier Evaluation en parcourant un keypath de offer.groups.items. Dans le second cas, vous devez parcourir uniquement le keypath de la relation items de l'objet Evaluation avec items.

Notez que la manière dont vous affichez tout cela dans l'interface utilisateur est indépendante du modèle de données. Une fois que vous avez les objets en main, vous pouvez les trier ou les organiser comme vous le souhaitez en fonction des besoins de la vue actuellement utilisée.

Quelques conseils d'adieu: Core Data n'est pas SQL. Les entités ne sont pas des tables. Les objets ne sont pas des lignes. Les attributs ne sont pas des colonnes. Les relations ne sont pas des jointures. Core Data est un système de gestion de graphe d'objet qui peut ou non persister dans le graphe d'objets et peut ou non utiliser SQL loin derrière la scène pour le faire. Si vous essayez de penser aux données de base en termes SQL, vous risquez de vous méprendre complètement sur les données de base et d'avoir beaucoup de chagrin et de perdre du temps.

Fondamentalement, oubliez tout ce que vous savez sur SQL. Cette connaissance ne vous aidera pas à comprendre les données de base et entravera activement votre compréhension de celle-ci.