Datenbank für App

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Datenbank für App

    Hallo zusammen,

    ich bin neu in der iOS- / OSX-Programmierung. Ich habe bereits in ABAP programmiert und kenne mich mit relationalen Datenbanken aus. Ich habe mir ein Macbook gekauft, XCode installiert und ein wenig "herumprobiert" anhand von ein paar Tutorials, die ich im Netz gefunden habe. Soweit zur Info, um meine Vorkenntnisse etwas einordnen zu können.

    Ich möchte eine App für iOS Mobilgeräte (iPad, iPhone, iPod touch und wer weiß was noch kommt) sowie für Mac OSX entwickeln, die über iCloud synchronisiert werden kann. Der Nutzer soll über die App Einträge in Einer Datenbank, die aus mehreren Tabellen besteht vornehmen können. Löschen und Ändern von Einträgen soll ebenfalls möglich sein - also insert, delete und modify. In der Haupttabelle erwarte ich etwa bis zu 50.000 Einträge, die sich über die Zeit ansammeln können.
    Ich bin mir gerade nicht 100%ig sicher, dass die iCloud-Synchronisation auch mit Apps unter OSX funktioniert. Daher nehmt diesen Punkt bitte nicht als zwingende Voraussetzung.

    Ich habe in XCode bereits den Bereich Core Data entdeckt. Wie ich an diversen Stellen gelesen habe, handelt es sich dabei nicht um eine relationale Datenbank. Warum nicht und was es letztendlich stattdessen ist, erschließt sich mir bisher noch nicht. Hier im Forum habe ich gelesen, dass teilweise SQLite-Datenbanken in iOS-Apps genutzt werden.

    So, jetzt letztlich doch noch die eigentliche Frage. Welche Art Daten zu persistieren würde ein erfahrener iOS-/OSX-Entwickler bevorzugen und warum?

    Vielen Dank für Eure Hilfe
    Chris1981

  • Chris1981 schrieb:

    Wie ich an diversen Stellen gelesen habe, handelt es sich dabei nicht um eine relationale Datenbank.

    +hach+ Sehr gute Vorbereitung.
    Ich mag dich jetzt schon. :)

    Chris1981 schrieb:

    Warum nicht und was es letztendlich stattdessen ist, erschließt sich mir bisher noch nicht.

    Ich versuche mal, dir das einigermaßen verständlich zu beantworten - und dann wirst du auch die Antwort auf deine Frage eigentlich herauslesen können: Core Data. ;)

    Also, was du gehört/gelesen hast, ist beides korrekt.
    Core Data ist keine Datenbank. Weder relational noch sonst irgendwas.
    Die iOS Apps mit Core Data speichern ziemlich alles in SQLite Datenbanken.

    Ich weiß, das klingt nach einem großen fetten WTF???.
    Core Data bildet einen Objektgraphen ab. Es ist also völlig wurst, ob du dein Datenmodell mit NSObject im Code zusammenmodellierst oder den Entity Editor und NSManagedObject nutzt.
    Du hast es immer, zu jeder Zeit und an jeder Stelle mit Objekten zu tun. (Du kannst ihnen beispielsweise eigene Methoden unterjubeln - versuch das mal bei einer Tabelle.)

    Damit der Zugriff performant erfolgen kann, werden die Objektgraphen in einer SQLite Datenbank persistiert. Das geschieht voll automatisch und hat gegenüber dem Speichern als XML oder Binary auf dem Mac einen entscheidenden Vorteil:
    Core Data kann dynamisch benötigte Objektinhalte nachladen, was Speicher, Rechenleistung und damit Akkuleistung spart.

    Und von all dem bekommst du überhaupt nichts mit. Es sei denn, du versuchst, Core Data wie eine Datenbank zu behandeln. ;)

    Natürlich kannst du dann nicht einfach eine SQL Struktur eines Servers nehmen und in deine App pappen.
    Du solltest also die Daten irgendwie abholen und in Core Data umwandeln, damit das läuft.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Hallo Lucas,

    vielen Dank für die schnelle Antwort und die erläuternden Ausführungen. Danach verstehe ich Core Data als eine Art Zwischenschicht, die die Datenbank verwaltet - also eine Art DBMS.
    Core Data bildet einen Objektgraphen ab.
    Was ist dabei der Unterschied zu einem relationalen Datenbankmodell? Bzw. wie bilde ich die Relationen meiner relationalen Datenbank, die ich konzipiert habe in Core Data ab? Wenn ich mir das in XCode 4 anschaue, dann sieht das alles grundsätzlich sehr einfach aus. Mit den diversen Klassen NSObject, NSManagedObject etc. habe ich mich noch nicht weiter auseinandergesetzt. Die benötige ich wahrscheinlich für den Zugriff auf die Daten, oder?

    Viele Grüße
    Chris1981

  • Nun ja, primaryKeys und foreignKeys fallen komplett raus und damit ein Gutteil der Zwischentabellen.
    Die Klassen für jede einezlene Entität erstellt Dir Xcode quasi auf Knopfdruck.

    CoreData schnell und kompakt findest Du hier mit einer recht brauchbaren Helperklasse umgesetzt:
    amazon.de/Apps-mit-entwickeln-…TF8&qid=1348676488&sr=8-2

    Ich bin mittlerweile dazu übergegangen, vollständig auf Plists und Serialisierung im klassischen Sinne zu verzichten und nur noch mit CoreData zu arbeiten.
    wunderbar, konsistent (sofern man die Normalisierungsregeln trotzdem beherrscht) und stets nachvollziehbar.
    Literatur ist auch reichlich vorhanden, nur auf 99% der Tuts im Internet solltest Du verzichten. Die sind stellenweise grausam und fehlerhaft.

    Liebe Grüße
    Karin

  • Chris1981 schrieb:

    Hallo Lucas,

    vielen Dank für die schnelle Antwort und die erläuternden Ausführungen. Danach verstehe ich Core Data als eine Art Zwischenschicht, die die Datenbank verwaltet - also eine Art DBMS.

    +ähm+
    Ja, es verwaltet die Datenbank. Aber es verwaltet genauso XML oder Binärdateien. Je nach OS und Einstellung.
    Zwischenschicht trifft es ganz gut, DBMS eher nicht so. Ist halt nicht an die Datenbank gebunden.

    Chris1981 schrieb:

    Core Data bildet einen Objektgraphen ab.
    Was ist dabei der Unterschied zu einem relationalen Datenbankmodell? Bzw. wie bilde ich die Relationen meiner relationalen Datenbank, die ich konzipiert habe in Core Data ab? Wenn ich mir das in XCode 4 anschaue, dann sieht das alles grundsätzlich sehr einfach aus. Mit den diversen Klassen NSObject, NSManagedObject etc. habe ich mich noch nicht weiter auseinandergesetzt. Die benötige ich wahrscheinlich für den Zugriff auf die Daten, oder?


    Ganz einfach: du hast eine Person mit der Relation Arbeitgeber. Wir sind altmodisch und definieren diese als 1:n - ein Arbeitgeber pro Person, n Personen pro Arbeitgeber.

    In SQL holst du eine spezielle Person via

    XML-Quellcode

    1. select * from Person where id=1;


    In Objective-C eher ein

    C-Quellcode

    1. Person * person = [personsArrayController objectAtIndex:1];


    Die Relation löst du in SQL dann so auf:

    XML-Quellcode

    1. select * from Person p inner join Company c on p.companyID==c.id where c.id=1

    Die Datenbank rattert dann alle Personen durch und wirft alle raus, auf dass das join nicht trifft.

    In Objective-C eher ein:

    C-Quellcode

    1. NSSet * allEmployers = [[companyArrayController objectAtIndex:1] employers]


    Du fragst immer die Objekte selbst, und es gibt auch keine andere Möglichkeit als die Objekte selbst zu fragen.
    Den Normalisierungskram kannst du vornehmen wie in einer Datenbank. Das Entity-Relationship-Krams passt auf alle Entities und Relationships, also auch die zwischen Objekten.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Ich widerspreche Lucas nur ungern. Eigentlich tu ich das auch nicht, aber das Beispiel mit Arraycontrollern mischt zwei Dinge, Datenmodell und Controller.

    NUR im Datenmodell sieht das in Core Data etwa so aus (Klartext, keine Syntax):

    Personen einer Adresse holen: NSSet *personenDieIchWill = dieseAdresse.personen (kein Select über die Personen!)
    Adresse (1) einer Person (n) zuordnen: person.adresse = dieseAdresse
    usw.

    Kurzum: mit Keys hast Du in CD nichts zu tun, auch nicht bei einer Suche. Du arbeitest nur auf der Ebene der Objekte und deren Attribute

    Du kannst auch weitere Attribute in Deine Objekte einbauen, die nicht unbedingt direkt im Datenmodell persistent abgebildet sein müssen, z.B. [dieseAdresse aeltestePerson]. Im Modell der Adresse ist das einfach eine Methode, die ein Objekt Person zurückliefert.

    No.

  • norbi schrieb:

    Ich widerspreche Lucas nur ungern. Eigentlich tu ich das auch nicht, aber das Beispiel mit Arraycontrollern mischt zwei Dinge, Datenmodell und Controller.

    Richtig. Nur wird es ohne irgend eine Kontrollschicht schwierig, an überhaupt irgendwelche Daten ohne Controller heran zu kommen.
    Wie im normalen Objektleben halt auch: deine Objekte sind zwar alle da, doch ohne Referenz darauf kannst du nichts damit anfangen.

    Als Mischung würde ich es auch nicht ansehen.
    Denn in den SQL Beispielen nutze ich eine Abfragesprache. Die hat ja nun auch nichts mit dem zu Grunde liegenden Datenmodell zu tun. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P