Core Data vs. SQL oder & SQL?

    • Core Data vs. SQL oder & SQL?

      Hallo zusammen,

      ich bin gerade dabei mir Swift beizubringen und hab hierzu schon ein Buch gelesen (Apps für IOS 10 professionell entwickeln von Thomas Hillmann), welches ich nebenbei sehr empfehlen kann.
      Nur stellt sich mir aktuell eine Frage, die Ihr mir hoffentlich beantworten könnt. Einerseits wird gesagt, daß Core Data keine Datenbank ist, dennoch verhält es sich m.e. wie eine. Manchmal sehe ich im Netz Videos, in denen eine SQL Datenbank in die App integriert wird, manchmal nicht.

      Da ich vor habe, eine App zu schreiben, die sehr umfangreiche Daten durch die Usereingaben erhalten wird, die gespeichert werden und veränderbar sind und ich diese später auch mal statistisch auswerten möchte, stellt sich mir jetzt die Frage, was ich machen soll/muß. Leider habe ich hierzu auch kein Buch gefunden, welches sich explizit um dieses Thema dreht. Insbesondere keines in deutsch.

      Ich hoffe mir kann hier jemand etwas Licht ins Dunkel bringen, wie Core Data und SQL Datenbanken zusammenhängen und ggf. auch den ein oder anderen Literaturtipp geben.



      Vielen Dank!
    • Würde mich wundern, wenn Du nicht genug im inet zu dem Thema Core Data vs. SQLite findest...

      Bertone105 schrieb:

      die sehr umfangreiche Daten durch die Usereingaben erhalten wird
      Weiß nicht was Du unter Umfangreich verstehst, aber ein Nutzer umfangreich Daten einzugeben zu lassen, verschreckt doch die Leute und es dauert weit länger als die Ewigkeit. Unter der Vorrausetzung, dass du das gleiche unter umfangreich verstehst wie ich. Oder sollen das mehere Anwender machen? - Brauchst Du dann vllt. einen externen Service dazu?

      Um welche Daten geht's eigentlich? Um dir besser zu helfen, musst Du das genauer spezifieren. Vllt. brauchst Du ja keine Relationale DB. Vllt. etwas gemischtes oder es geht einfacher.
    • Core Data ist Apples Persistenz Framework. Wenn Du ein Buch über das Entwickelt unter iOS hast, sollte das unbedingt darin erklärt sein, denn das eine Basis Technologie auf Apples Plattformen. – Ansonsten wird das auch hier erklärt.

      P.S.: Und wenn Du, wie bereits von manch erwähnt, uns die Details verrätst, dann kann Dir wahrscheinlich auch jemand einen konkreten Rat zu deiner Fragestellung geben.
      * Kann Spuren von Erdnüssen enthalten.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

    • Hallo zusammen,

      stellt euch vor, daß jemand in der App seine Bilanz eintippt. Das sind also pro Jahr locker 100 Positionen. Für das Folgejahr werden aber zu seiner Erleichterung die Werte aus dem Vorjahr übernommen und ggf. z.B. automatisch mit der Inflation indexiert. Er kann aber auch diese vorgegebenen Werte selbst mit harten Werten überschreiben und dann speichern. Das Ganze soll er dann über mehrere Jahre machen können. Zugang dazu hat übrigens immer nur 1 User, es gibt also kein Datensharing untereinander, was z.B. eine Cloud erfordern würde.

      In dem Buch, welches ich gelesen habe war ein Kapitel über Core Data drin, so daß ich schon kapiert habe, wie Core Data grundsätzlich funktioniert. Ich verstehe nur nicht, ob ich bei Core Data grundsätzlich eine Mysql Datenbank im Hintergrund benötige oder nicht.

      In Core Data gebe ich ja die Verbindungen der jeweiligen Daten an und wo sie in der App eingegeben bzw. angezeigt werden etc.. Aber wo werden die dann später gespeichert? Sicher nicht auf dem Device sondern auf einem Server irgendwo auf dieser Welt (so zumindest mein Wunsch). Und in welchem Dateiformat wird das gemacht? Muß ich mich darum kümmern, oder macht das die App von alleine? Schließlich will ich die Daten aller User ja später sammeln und auswerten. Z.B. um sagen zu können, die durchschnittliche Bilanzsumme meiner User beträgt X, oder in Deutschland sind die Bilanzen meiner User höher als in Frankreich.

      Ich hoffe damit euch meine Frage etwas verständlicher gemacht zu haben.
    • Coredata hat als Storage Engine eine Sqlite Datei. Die Daten liegen also als file auf dem device und nicht irgendwo auf einem Server. Warum sollten sie das auch. In deinem anwendungsfall würde das den User nur unnützerweise zwingen immer online zu sein und sein datenvolumen zu dezimieren.

      Gruß

      Claus
      2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

      Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
    • Moin moin.


      Von Bilanzen habe ich keine Ahnung, dafür gibt es die Buchhaltung. Aber ich betrachte das als Beispiel, welches man beliebig modellieren kann.

      Bertone105 schrieb:

      In dem Buch, welches ich gelesen habe war ein Kapitel über Core Data drin, so daß ich schon kapiert habe, wie Core Data grundsätzlich funktioniert. Ich verstehe nur nicht, ob ich bei Core Data grundsätzlich eine Mysql Datenbank im Hintergrund benötige oder nicht.
      Nein, das hätte aus dem Buch hervorgehen müssen, denn mit MySQL hat Core Data überhaupt gar nichts zu tun.

      Bertone105 schrieb:

      In Core Data gebe ich ja die Verbindungen der jeweiligen Daten an und wo sie in der App eingegeben bzw. angezeigt werden etc.. Aber wo werden die dann später gespeichert?
      Du legst am Anfang fest wo der Store gespeichert wird.

      Bertone105 schrieb:

      Sicher nicht auf dem Device
      Doch natürlich auf dem Gerät. Es muss ja verfügbar sein, wenn Du die App wieder startest. – Siehe Persistenz.

      Bertone105 schrieb:

      sondern auf einem Server irgendwo auf dieser Welt (so zumindest mein Wunsch).
      Nein. -> Weil Core Data keine Datenbank ist.

      Bertone105 schrieb:

      Und in welchem Dateiformat wird das gemacht? Muß ich mich darum kümmern, oder macht das die App von alleine?
      Das kannst Du aussuchen und legst es am Beginn fest. Es spielt in der Regel aber eine untergeordnete Rolle.

      Bertone105 schrieb:

      Schließlich will ich die Daten aller User ja später sammeln und auswerten.
      Das ist die Information, die ganz vorne an den Anfang gehört hätte...

      Bertone105 schrieb:

      Z.B. um sagen zu können, die durchschnittliche Bilanzsumme meiner User beträgt X, oder in Deutschland sind die Bilanzen meiner User höher als in Frankreich.
      ...denn das würde man mit einem Server und einer Datenbank machen.
      * Kann Spuren von Erdnüssen enthalten.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

    • Bertone105 schrieb:

      guter Einwand mit dem Online Thema. Dann muß ich schauen, daß die Daten übermittelt werden, sobald der User mal wieder online ist. Denn einen Abzug dieser Daten möchte ich haben.
      Mit Hinblick darauf böte sich evtl. CouchDB an. Siehe “Offline First applications for Mobile applications...".

      P.S.: Video zu dem Thema. Mobiler Einsatz von CouchDB
      * Kann Spuren von Erdnüssen enthalten.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von NSObject ()

    • Welcher User wird denn sowas machen? Mal davon abgesehen, dass man Bilanzen garcnicht selber erstellen darf ,sondern das ein Steuerberater machen muss, müsste der User dann die Werte die er eh schon auf Papier hat, mühsam in sein Handy tippen, nur damit du die Daten sammeln kannst? Was soll denn da der Mehrwert für den User sein? Oder verstehe ich das Wort Bilanz hier falsch?
      2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

      Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
    • @Claus', das mit der Bilanz ist nur ein Beispiel, welches jedoch dem Umfang dessen was ich vorhabe recht nahe kommt.

      @manoh, ich wollte damit sagen, daß nicht mehrere User auf die gleichen Daten zugreifen müssen. Allerdings soll später jeder User eine eindeutige ID bekommen, so daß ich später alle Daten und die Änderungen daran über die Jahre einem jeweiligen User zuordnen kann, ohne dessen Name und postalische Adresse etc. kennen zu müssen und zu wollen.
      Ein anderes abstraktes Beispiel hierzu: Die User geben ein, wieviel sie im Monat für Kino ausgeben. Ich möchte später z.B. auswerten können, ob die Deutschen oder die Franzosen mehr im Monat für Kino ausgeben. Ich will einfach später nachvollziehen können, was ein User X so alles eingegeben und im laufe der Zeit geändert hat.

      @NSObject, das mit CouchDB und den anderen infos schau ich mir mal an. Vielen Dank schon mal für die Hinweise.
    • Wenn Du es mit CoreData machst, programmierst Du Deine App objektorientiert und Deine Daten sind ebenso DatenOBJEKTE. Damit kannst Du alles machen, natürlich auch auswerten oder exportieren. Um das Speichern brauchst Du Dich fast nicht zu kümmern.

      Wenn Du mit einer SQL-Datenbank arbeitest, musst Du zusätzlich (!) die Datenschicht, die gespeichert werden muss programmieren (einfügen, löschen, ändern, abfragen und vor allem die Datenmodelle der Datenbank und des Programms synchron halten).

      Relativ simpel, was der bessere Deal ist, vor allem für Anfänger.

      Sobald Du Multiuser brauchst, vergiss CoreData.

      LG Norbert
    • Hallo Norbert,

      danke für die einleuchtende Erklärung. Eine Frage noch, was verstehst du unter Multiuser? Zeitgleicher Zugriff mehrerer User auf die gleiche Datei?
      Oder zählt auch das Aufzeichnen des Nutzerverhaltens meiner User in ein und der selben Datenbank dazu? Denn das ist was ich machen möchte. Die Datenbank, welche auf einem Server liegen wird, soll alle Eingaben und Änderungen der User anonym speichern.

      Gruß mac