Моделирование основных данных из SQL

Question

Я собираюсь начать использовать Core Data в первый раз, и я стараюсь, чтобы моя модель данных была приличной, прежде чем я заберусь слишком далеко и осознаю, что это не так. Я имею опыт работы с SQL и предположил (как представляется, ошибочно), что Core Data был SQLite под другим именем. Я читал, что большие неудачи проектов Core Data от новичков в том, что они пытаются применять концепции RBMS в Core Data, и это не всегда лучший способ. Я издевался над небольшой схемой SQL, которую я хотел использовать в этом тестовом проекте. Но не знаете, как его следует изменить, чтобы он соответствовал основным данным? Так что если кто-нибудь может дать некоторые указатели для моего сценария, что было бы здорово

Answer 1

Забудьте настойчивость (поставив его на диске). Как бы вы моделировали это только в структурах данных в памяти? Это, как правило, очень близко к тому, как вы могли бы моделировать его в Core Data. Core Data - это механизм персистентности графического объекта. Если ваш графический объект был достаточно мал, чтобы соответствовать памяти, в принципе вам вообще не понадобится Core Data (это не совсем так: Core Data имеет некоторые другие функции, но позволяет эффективно обрабатывать массивный граф объектов - это заголовок один).

Есть несколько отличий в основных данных, таких как отношения, требующие обратного (так что если у игрока есть командные отношения, тогда у команды должно быть отношение игроков). Но в принципе, моделируйте это так, как вы моделируете объекты, потому что это то, что они есть.

Так что я не совсем понимаю некоторые из ваших моделей, но общие «игроки на командах и командах имеют игры и игры в сезон», я бы предположил (упрощенную) модель в этих строках:

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 
} 

Я сделал это homeTeam/awayTeam, так что было легко обеспечить ровно две команды. Но вы также можете сделать это следующим образом:

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 
} 

Многие-ко-многим не волшебная вещь, которую вы должны создать для промежуточных в основных данных. Они просто «для многих» отношений, где обратное также «для многих». Нет необходимости в ключах или любом из них. Это все просто объекты. Вот как вы думаете о Core Data по большей части.

(Я написал это в форме, которая, надеюсь, имеет смысл, даже если она не является абсолютно законной в Xcode 7.3. Типы отношений будут нетипизированы NSSet.Это все значительно улучшено в Xcode 8 и iOS 10 и вы получаете сильные типы, но я не сделал достаточной работы там, чтобы быть уверенным, что это довольно синтаксис или нет.)