Core Data Modeling von SQL

Question

Ich bin dabei, Core Data zum ersten Mal zu verwenden, und ich versuche, sicherzustellen, dass mein Datenmodell anständig ist, bevor ich zu weit in es hinein gehe und es realisiere. Ich bin in SQL erfahren und vermutete (falsch scheint), dass Core Data SQLite unter einem anderen Namen war. Ich habe gelesen, dass Core-Data-Projekte von Newcomern darin versagt haben, RBMS-Konzepte in Core Data zu implementieren, und das ist nicht unbedingt der beste Weg. Ich habe ein wenig SQL-Schema verspottet, das ich in diesem Testprojekt verwenden wollte. Aber unsicher, wie es geändert werden sollte, um besser mit Kerndaten zu passen? Also, wenn jemand einige Hinweise für mein Szenario geben könnte, die würde

Answer 1

Vergessen Persistenz (legt es auf der Festplatte) groß sein. Wie würden Sie dies nur in In-Memory-Datenstrukturen modellieren? Das ist normalerweise sehr ähnlich wie Sie es in Core Data modellieren würden. Core Data ist eine Objektgraph-Persistenz-Engine. Wenn Ihr Objekt-Graph klein genug wäre, um in den Speicher zu passen, würden Sie grundsätzlich keine Core-Daten benötigen (das stimmt nicht ganz; Core Data hat einige andere Funktionen, aber Sie können effizient mit einem massiven Objekt-Graphen umgehen) ein).

Es gibt ein paar Unterschiede in den Core-Daten, z. B. jede Beziehung, die eine Umkehrung erfordert (wenn der Spieler eine Teambeziehung hat, sollte Team eine Spielerbeziehung haben). Aber modelliere es so, wie du Objekte modellierst, denn das sind sie.

Also ich verstehe nicht ganz etwas von Ihrem Modell, aber eine generische "Spieler sind auf Teams und Teams haben Spiele und Spiele sind in einer Saison", würde ich ein (vereinfachtes) Modell in diese Richtung vorstellen:

class Player: NSManagedObject { 
    @NSManaged var name: String 
    @NSManaged var team: Team? // 0..1 relationship 
} 

class Team: NSManagedObject { 
    @NSManaged var name: String 
    @NSManaged var players: Set<Player> // 0..* 
    @NSManaged var homeGames: Set<Game> // Inverse for homeTeam (See more below) 
    @NSManaged var awayGames: Set<Game> // Inverse for awayTeam 

    // There are more powerful and efficient ways to do this, but a simple convenience example 
    var games: Set<Game> { return homeGames + awayGames } 
} 

class Game: NSManagedObject { 
    @NSManaged var homeTeam: Team 
    @NSManaged var awayTeam: Team 
    @NSManaged var season: Season 
    @NSManaged var date: NSDate 
} 

class Season: NSManagedObject { 
    @NSManaged var name: String 
    @NSManaged var games: Set<Game> // Note again the inverse relationship 
} 

Ich habe es gemacht homeTeam/awayTeam, so dass es einfach war, genau zwei Teams zu erzwingen. Aber man könnte es auch auf diese Weise tun:

class Team: NSManagedObject { 
    @NSManaged var name: String 
    @NSManaged var players: Set<Player> // 0..* 
    @NSManaged var games: Set<Game> // Many to many relationship 
} 

class Game: NSManagedObject { 
    @NSManaged var teams: Set<Team> // Many to many relationship 
    @NSManaged var season: Season 
    @NSManaged var date: NSDate 
} 

Many-to-many-Beziehungen sind nicht eine magische Sache, die Sie Zwischenprodukte für die in Core Data erstellen müssen. Sie sind nur "zu viele" Beziehungen, wo die Umkehrung auch "zu vielen" ist. Es gibt keine Notwendigkeit für Schlüssel oder irgendetwas davon. Es sind alles nur Objekte. So denken Sie zum größten Teil an Core Data.

(Ich habe dies in einer Form geschrieben, die hoffentlich Sinn macht, obwohl es in Xcode 7.3 nicht absolut legal ist. Die Typen der Beziehungen sind ein untypisiertes NSSet. Dies ist alles drastisch verbessert in Xcode 8 und iOS 10 und Du bekommst starke Typen, aber ich habe dort nicht genug gearbeitet, um sicher zu gehen, ob das die Syntax ist oder nicht.)