Welchen Datentyp für Vokabeln (Vokabeltrainer) verwenden?

[belinea]

Ich mochte einen kleinen simplen Vokabeltrainer erstelln. Ich stehe jetzt vor der Wahl mein Wörterbuch in einem mehrdimensionalen Array oder in einem Dictionary abzuspeichern.

Könntet ihr mir einen Datentyp empfehlen den ich verwenden sollte?

 

[ecco55]

Ich würde das ganze über Core Data machen . Ist gerade für so große Datenbanken, wie für Vokabeln, empfehlenswert. Falls du nun vor der Frage stehst, wie du das anstellen sollst:
http://www.raywenderlich.com/85578/first-core-data-app-using-swift
Gruss

 

[belinea]

Ich werde SQLite verwenden. Erstens da ich mit der SQL Syntax schon vertrautbin und zweitens da ich bei CoreData ein ungutes Gefühl habe völlig ausgeliefert zu sein auf ein völlig geschlossenes Format.

Bei einer Datenbank habe ich immer Zugriff auf meine Daten und kann die auch mit andere Tools verändern.

Bei CoreData wäre ich völlig Abhängig von Apple.

Aber eine gute Idee erst gar kein festes Array zu verwenden das in Sourcecode steht. Mit einer Datenbank lässt sich mit wenig Aufwand eine Wörterbuch-Verwaltung nachrüsten.

 

[Marcel Bresink]

Ich werde SQLite verwenden. Erstens da ich mit der SQL Syntax schon vertrautbin und zweitens da ich bei CoreData ein ungutes Gefühl habe völlig ausgeliefert zu sein auf ein völlig geschlossenes Format.

Da hast Du etwas missverstanden.

Gefragt war doch nach einer Datenstruktur bei der Programmierung in einer Swift-Umgebung. SQLite ist aber keine Datenstruktur.

CoreData stellt ein objektorientiertes Datenmodell zur Verfügung, mit dem man große Datenmengen unabhängig vom konkreten Format, in dem die Daten später in Dateien verwandelt werden ("Persistenz"), im Programm handhaben kann. Standardmäßig speichert CoreData die Dateien wahlweise in einem eigenen Binärformat, in XML oder in einer SQLite-Datenbank ab.

 

[belinea]

Achso. Dann hätte ich schon CoreData verwenden können und würde trotzdem an die Daten kommen (per XM oder SQLite).

Jetzt habe ich es mit FMDB und einer SQLite Datenbank gelöst. Wäre mit CoreData wohl nochmals um einiges schneller und mit deutlich weniger Code gegangen.

 

[belinea]

Meine Abneigung zu CoreData hat sich voll bestätigt.

Ein bestehendes Datenbank Modell zu verändern gleicht einem Ritt durch die Hölle. Einer Entity eine neue Attribute hinzuzufügen (wenn schon Daten vorhanden sind) der Entity geht nur mit riesigem Aufwand oder dem löschen des ganzen Datenbestandes.

Unter SQL füge ich einfach ein neues Field ein und fertig.

Von CoreData bin ich erstmal geheilt.

 

[MacApple]

Ein bestehendes Datenbank Modell zu verändern gleicht einem Ritt durch die Hölle. Einer Entity eine neue Attribute hinzuzufügen (wenn schon Daten vorhanden sind) der Entity geht nur mit riesigem Aufwand oder dem löschen des ganzen Datenbestandes.

Nun, wenn du Core Data als Datenbank betrachtest, wirst du dich damit immer schwer tun, denn Core Data ist nun mal keine Datenbank. Um bestehende Datenmodelle zu verändern bietet Core Data auch Versionierung und Datenmigration.