Ho un modello di dati che sto provando a trasferire da una struttura di tabella basata su SQLite a un modello di dati di base. La mia struttura SQLite ha una tabella Zone e una tabella TransitLogs. Un transit può avere la seguente (nel mio schema SQLite) start_zone_id end_zone_idDati principali più relazioni con la stessa entità
ognuno dei quali è una chiave esterna alla tabella zone. Funziona bene in SQL. Ma quando mi trasferisco su Core Data ho difficoltà a capire come modellarlo.
Il mio primo tentativo mi ha avere due relazioni nella mia transit entità con una relazione startZone e di meta attributi che puntano a una Zona (purtroppo non è stato in grado di inviare uno screenshot di Xcode come questo è il mio primo post qui)
La domanda che ho è come gestire la relazione inversa per gli attributi della relazione startZone e endZone. Non ho bisogno di loro? Nella documentazione e nei libri che ho letto su questo argomento, è meglio usare sempre una relazione inversa, ma mi chiedo in merito a questa particolare situazione se non si applica. Oppure sto semplicemente modellando questo in modo errato in Core Data.
Grazie per qualsiasi consiglio.
Mike
Si noti che le relazioni inverse sebbene non assolutamente richieste in un senso di compilazione/sintassi sono necessarie per consentire a CoreData di aggiornare i molti set quando quello viene eliminato. –
Se non hai mai bisogno di andare da Zone a TransitLogs, puoi fare a meno della relazione inversa. Non sembra che l'eliminazione di un TransitLog abbia effetti sul suo startZone e endZone. Quindi, sembra che tu possa andare bene per omettere le relazioni inverse. Tuttavia, se pensi di non voler mai, per esempio, conta quanti registri di transito provengono da ciascuna zona, quindi potresti voler aggiungere relazioni inverse ora e risparmiarti lo sforzo di migrazione in seguito. – westsider