2011-01-26 16 views
5

Tengo un modelo de datos que intento exportar desde una estructura de tabla basada en SQLite a un modelo de datos básicos. Mi estructura de SQLite tiene una tabla de Zonas y una tabla de TransitLogs. Un TransitLog puede tener lo siguiente (en mi esquema sqlite) start_zone_id end_zone_idRelaciones múltiples de datos principales a la misma entidad

Cada uno de los cuales es una clave externa a la tabla de zonas. Esto funciona bien en SQL. Pero cuando me cambio a Core Data tengo problemas para entender cómo modelar esto.

Mi primer intento me ha tener dos relaciones en mi transitlog entidad con una relación StartZone y Endzone atribuye ese punto a una zona (lo siento, no fue capaz de publicar una captura de pantalla de Xcode ya que este es mi primer post aquí)

La pregunta que tengo es cómo manejar la relación inversa para los atributos de relación startZone y endZone. ¿No los necesito? En la documentación y los libros que he leído sobre este tema, es mejor utilizar siempre una relación inversa, pero me pregunto acerca de esta situación particular si no se aplica. O simplemente estoy modelando esto incorrectamente en Core Data.

Gracias por cualquier consejo.

Mike

Respuesta

3

Puede tener dos relaciones separadas a muchos en la entidad Zona que apuntan a transitlog, llamado algo así como startLogs y endLogs. Esos serían los inversos para startZone y endZone, respectivamente.

+1

Tenga en cuenta que las relaciones inversas aunque no son absolutamente necesarias en un sentido de compilación/sintaxis son necesarias para permitir que CoreData actualice los muchos conjuntos cuando se elimina uno. –

+0

Si nunca va a necesitar ir de Zones a TransitLogs, puede hacerlo sin la relación inversa. No parece que la eliminación de un TransitLog tenga ningún efecto en su startZone y endZone. Entonces, parece que estaría bien omitir las relaciones inversas. Sin embargo, si crees que alguna vez querrás, digamos contar cuántos registros de tránsito se originan en cada zona, entonces quizás quieras agregar relaciones inversas ahora y ahorrarte el esfuerzo de migración más adelante. – westsider

1

Gracias chicos - ambas respuestas ayudaron mucho. Westsider tiene razón, actualmente no tengo necesidad de atravesar la zona hasta los TransitLogs y era por lo que me preguntaba. Pero dicho esto, supongo que es posible que los necesite en algún momento (miles de usuarios claman por ello con suerte;)) así que probablemente sea mejor modelarlo ahora.

Gracias de nuevo por las respuestas.

2

Las versiones y migraciones de modelos no triviales pueden ser un fregadero en tiempo real, especialmente la primera vez. Por esa razón, además de que Apple recomienda su uso, recomendaría agregar las relaciones inversas.

Dicho esto, he encontrado al menos un caso en el que simplemente no tiene sentido agregar una relación inversa, y todo funciona bien. Pero en ese caso, fue (y sigue siendo) extremadamente difícil encontrar un escenario donde la relación inversa sería alguna vez útil o necesaria.

Cuestiones relacionadas