2011-12-22 22 views
5

Tengo dificultades para diseñar un modelo coreData donde tengo solo un tipo de entrada llamada "Tareas pendientes". Cada entrada To-Do tiene 0, 1, 2, ..., o n relaciones con otras (sub) entradas como To-Do. Por lo tanto, las relaciones entre las entradas de tareas pendientes diseñan una estructura de árbol con una cantidad indefinida de nodos secundarios. El siguiente gráfico debe ilustrar el caso (E = entrada de datos del núcleo):Datos principales: Cómo diseñar una estructura de datos de árbol a partir de una entrada de datos central

  E        
      /|\       
     /| \      
     E E E      
     /\    
    / \   
     E  E    
    /|\     
    E E E   

Mi suposición fue modelar que los datos como se ilustra en el siguiente gráfico. No elegí la relación inversa porque Xcode hizo una relación de muchos a muchos que no coincide con el diseño del árbol.

enter image description here

También vi en el data model inspector algo que se llama "entrada principal". Así que empecé a creer que podría tener que crear una segunda entrada llamada "To-Do-Child" con los mismos atributos y hacer la otra entrada a la entrada principal. El manual me dice que este podría ser el camino equivocado para ir ...

Preguntas:

  1. ¿Cómo puedo modelar este enfoque dentro del archivo central del modelo de datos? ¿Alguno de los mencionados es correcto?

  2. ¿Cómo podré recuperar todas las entradas pendientes de un nodo principal especificado? Como surgen de la misma entrada, tengo problemas para abordar el subárbol Tareas pendientes que quiero.

+0

Simplemente vinculo a esta pregunta que es un poco más útil que la respuesta aceptada http://stackoverflow.com/questions/16633907/model-a-tree-structure-in-core-data –

Respuesta

3

Creo que se necesita una relación de parent (entidad de destino es el de hacer la entidad) que sirve como destino para la relación inversa.

Las entradas en la parte superior del árbol tienen valor nulo para esta relación.

Para cualquier elemento de tarea pendiente, el conjunto devuelto por la relación childToDos tendrá todos los elementos secundarios. No importa que estos sean de la misma clase.

+0

Aha, buena idea. Pero luego vino a mi mente por qué no definir una segunda relación llamada 'parent'. ¿No haría eso el truco sin tener un nuevo atributo? ¿Entonces el primer acercamiento con la relación del yo sería el enfoque correcto? –

+0

Correcto, eso es lo que quise decir, lo siento. He actualizado la respuesta. – jrturton

Cuestiones relacionadas