Unter Verwendung von Kerndaten habe ich zwei Entitäten, die viele-zu-viele-Beziehungen haben. Damit:

Class A <<---->> Class B

Beide Beziehungen sind als "geordnet" eingerichtet, damit ich ihre Reihenfolge in einer UITableView verfolgen kann. Das funktioniert gut, kein Problem.

Ich bin dabei, iCloud mit diesem Core Data-Modell zu implementieren, und stelle fest, dass iCloud keine geordneten Beziehungen unterstützt. Daher muss ich die Reihenfolge irgendwie neu implementieren.

Ich habe dies mit einer anderen Entität gemacht, die problemlos eine Eins-zu-Viele-Beziehung hat. Ich füge der Entität ein 'order'-Attribut hinzu und speichere dort ihre Bestellinformationen. Bei einer Viele-zu-Viele-Beziehung benötige ich jedoch eine unbekannte Anzahl von Auftragsattributen.

Ich kann mir zwei Lösungen vorstellen, von denen mir keine ideal erscheint. Vielleicht fehlt mir etwas.

Option 1. Ich füge eine zwischengeschaltete Entität hinzu. Diese Entität hat eine Eins-zu-Viele-Beziehung zu beiden Entitäten wie folgt:

Class A <<--> Class C <-->> Class B

Das heißt, ich kann das Attribut für eine einzelne Bestellung in dieser Hilfsentität haben.

Option 2. Anstelle eines Bestellattributs, in dem eine einzelne Bestellnummer gespeichert ist, speichere ich ein Wörterbuch, in dem ich so viele Bestellnummern speichern kann, wie ich benötige, wahrscheinlich mit dem entsprechenden Objekt (ID?) Als Schlüssel und der Bestellnummer als Wert .

Ich suche nicht unbedingt nach Code, daher wären Gedanken oder Vorschläge willkommen.

0
Cai 3 Jän. 2016 im 22:35

2 Antworten

Beste Antwort

Ich denke, Ihre Option 1, eine "Join-Tabelle" mit einem Auftragsattribut zu verwenden, ist die praktikabelste Lösung für dieses Problem. In der Tat wurde dies in der Vergangenheit schon oft getan. Dies ist genau der Fall, für den Sie eine Join-Tabelle in Core Data verwenden würden, obwohl das Framework Ihnen bereits viele-zu-viele-Beziehungen bietet: Wenn Sie Informationen über die Beziehung selbst speichern möchten , ist dies genau der Fall dein Fall. Oft sind dies Zeitstempel, in Ihrem Fall handelt es sich um eine Sequenznummer.

Sie sagen: "... Lösungen, von denen mir keine ideal erscheint". Für mich scheint das oben Genannte tatsächlich "ideal" zu sein. Ich habe dieses Schema wiederholt mit großer Leistung und Wartbarkeit verwendet.

Das einzige Problem (obwohl es dasselbe ist wie bei einer Eins-zu-Eins-Beziehung) ist, dass Sie beim Einfügen eines Elements außerhalb der Reihenfolge viele Entitäten aktualisieren müssen, um die richtige Reihenfolge zu erhalten. Das scheint umständlich und könnte möglicherweise die Leistung beeinträchtigen. In der Praxis ist es jedoch ziemlich überschaubar und funktioniert ziemlich gut.


NB: Arrays oder Wörterbücher, die mit der Entität gespeichert werden sollen, um die Bestellinformationen zu verfolgen: Dies ist über sogenannte "transformierbare" Attribute möglich, aber der Overhead ist gewaltig. Diese Attribute müssen serialisiert und deserialisiert werden. Um eine Sequenznummer abzurufen, müssen Sie alle erhalten. Kaum eine attraktive Designwahl.

1
Mundi 3 Jän. 2016 im 23:28

Bevor wir mehr als 10 Jahre lang Beziehungen bestellt hatten, benutzten alle eine "Helfer" -Einheit. Das ist also das, was Sie tun sollten.

Zusätzlicher Hinweis 1: Dies ist keine "Hilfs" -Entität. Es ist eine Entität, die eine Tatsache in Ihrem Modell modelliert. In meinen Büchern hatte ich immer das gleiche Beispiel:

Sie haben eine Gruppenentität mit Mitgliedern. Jedes Mitglied kann vielen Gruppen angehören. Die "Helfer" -Entität ist nichts anderes als eine Mitgliedschaft.

Zusätzlicher Hinweis 2: Es ist schwierig, eine solche geordnete Beziehung zu synchronisieren. Aus diesem Grund erfolgt dies nicht automatisch. Sie müssen es jedoch tun. Da CD und Synchronisieren keinen Spaß machen, macht CD und Synchronisieren eines Modells mit geordneter Beziehung weniger als keinen Spaß.

0
Amin Negm-Awad 3 Jän. 2016 im 21:06