Core Data vs SQLite

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

    • Core Data vs SQLite

      Hallo,

      Ich setze mich gerade mit CoreData und SQLite auseinander. Ich habe eine Beispielanwendung, die mir Rezepte Speichert. Diese werden Kategorien zugeordnet, haben Zutaten und Zubereitungsschritte. Das ganze soll auch Cloud-Fähig sein. Um mal eine Größenordnung vorzugeben nehme ich mal an, die Anzahl der Rezepte soll bei ca 1000 liegen und jedes Rezept etwa 3 Bilder, 20 Zubereitungsschritte und 20 Zutaten haben. Jetzt stellen sich mir folgende Fragen:
      1) Ich lese oft, dass CoreData heute eher verwendet wird, als SQLite. Ich erkenne aber keinen Vorteil, der sich mir daraus ergibt. Einige Threads unter diesem hier ("Grenzen von Core Data" oder ähnlich) habe ich gelesen, dass nur CD Cloud-Fähig wäre. Wobei ich mir denke, dass ich doch genausogut von mir erstellte SQLite-Dateien über die Cloud synchronisieren kann. Oder gibt es da größere Hindernisse? Zumal steht in dem eben erwähnten thread, dass CD doch nicht unbedingt geeignet ist für Cloud-Dienste...
      2) Ich muss viele Join-Abfragen machen. Dazu ist CD ja scheinbar nicht so gut geeignet. Spielt das auch bei überschaubaren Datenmengen eine Rolle?
      3) Für mich ist es aber wichtig, dass ich Daten über andere DBMS einfügen und diese dann in SQLite importieren/überführen kann. Ist dies bei der Arbeit mit CD ohne großen Aufwand möglich? Die Frage stellt sich mir, da ja Metadaten (-tabellen) automatisch erstellt werden, wenn ich ein CD-Modell erstelle.
      3) Etwas praktisches, auf Frage 2 Bezogen. Wie gestalte ich bei CD mein Datenmodell? Es heißt ja man soll Tabellen so granular wie möglich halten, um direkte Abfragen zu ermöglichen (falls ich das richtig verstanden habe). In SQL würde ich das in etwa wie unten aufbauen. Wäre dieses Modell ungeeignet für CD?
      Rezept (RName,)
      Zubereitungsschritte (SchrittNr, RName,Beschreibung)
      Kategorie (KName)
      Zutat (ZName, Menge,Einheit)
      Bild (id, RName, BildName)
      HatKategorie (RName, KName)
      HatZutaten (RName, ZName)

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

    • Ja das mit großen dB stimmt wohl...
      Ich verstehe nur nicht ganz warum sqlite angeblich nicht mit iCloud unterstützt wird. Falls die dB klein ist kann ich diese ja wie jede beliebige andere Datei synchronisieren.
      ... Und wie sieht es aus mit datenmodellen in Core Data? Ich weiß, dass cd keine datenbank ist, aber die Modelle sind ja dem Modellen ähnlich. Wie gestalte ich ein solches Modell, damit es auf Core Data abgestimmt ist? Hat da evt jemand links zu dem Thema?

    • 1) Du kannst alles über iCloud (nicht) synchronisieren. Core Data synchronisiert allerdings regelmäßig lediglich Deltas.

      2) Mit Core Data musst du keine "Join-Abfragen" machen. Objective-C ist auch nicht so gut wie BASIC für goto-Sprünge geeignet.

      3) Du fügst bei Core Data nicht in eine DB ein, sondern in einen Objektgraphen. Woher die Daten kommen, ist erst einmal schnuppe. Das interne Format von Core Data ist versteckt und muss und sollte dich nicht interessieren.

      4) Ich weiß schon nicht, was diese komischen Unterstreichungen sollen. PK? Den gibt es in Core Data nicht, weil Beziehungen zwischen Objekten Beziehungen zwischen Objekten sind.
      Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
      25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    • 0) Ich habe kürzlich versucht, mich mit Äpfeln und Papiertüten zu beschäftigen. Das hatte ungefähr denselben Vergleichsgehalt.

      1) Core Data wird eher verwendet als SQLite. XML wird eher verwendet als xls. txt wird öfter verwendet als tex. Das liegt an der unterschiedlichen Verwendung.

      2) Du kannst bei Core Data keine Join Abfragen machen. Du kannst in SQLite keinen Objektgraphen abbilden. Du kannst in XML keine Tabellenlinien formatieren. Du kannst in xls keine variablen Styles hinterlegen. Du kannst in txt keine Formatinformationen abspeichern. Du kannst tex nicht ohne Umwege gerendert anzeigen. Du kannst keine Dinge in Äpfel verpacken und du kannst keine Papiertüten zum Erhöhen des Vitaminhaushalts verzehren.

      3) Meinetwegen kannst du die Infos aus einer CSV in ein Bild packen und dann in Core Data importieren. Um einen Importer wirst du nicht herum kommen.

      4) Das Modell ist auf SQL zugeschnitten. Das bringt dir in Core Data nix.
      Folgende Syntax in SQL für 'Finde alle Rezepte der Kategorie "vegan"': Tabelle 'Rezept', hole mir alle Rezepte. Dann zeige mir all jene, die in der Kategorie den Wert haben, der in der Tabelle 'Kategorie' den Wert 'vegan' beinhaltet.
      Folgende Sytax in Core Data für den selben Anwendungsfall: Objekt 'Kategorie' mit Namen 'vegan', zeige mir alle deine Rezepte.

      Wie granular man Tabellen halten soll weiß ich nicht. Es gibt Befürworter der Datenredundanz um die Strukturen übersichtlich zu halten.
      Ist mir aber auch wurscht, da bei Core Data nur interessiert, wie granular man Objekte halten soll.

      (Ich hoffe, ich konnte einigermaßen klarstellen, dass Core Data keine Datenbank ist und dass Core Data nicht wie eine Datenbank behandelt werden kann.)
      «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

    • Lucas de Vil schrieb:

      0) Ich habe kürzlich versucht, mich mit Äpfeln und Papiertüten zu beschäftigen. Das hatte ungefähr denselben Vergleichsgehalt.


      Uiuiui… Die Frage ist doch legitim.

      urindanger schrieb:

      Wie gestalte ich bei CD mein Datenmodell? Es heißt ja man soll Tabellen so granular wie möglich halten, um direkte Abfragen zu ermöglichen (falls ich das richtig verstanden habe). In SQL würde ich das in etwa wie unten aufbauen. Wäre dieses Modell ungeeignet für CD?


      SQLite ist eine klassische relationale Datenbank mit flachem (im Sinne von zweidimensionalen, nicht "flache Tabellen") Datenmodell. Vorteile sind zum Beispiel sehr hohe Transaktionsraten und eine einfache Datenstruktur mit standardisierter Abfragesprache.

      Ein Nachteil ist das du eigentlich zusammenhängende Strukturen auf verschiedene Tabellen verteilt hast, diese also erst durch Joins zusammenführen musst, und dann immer noch nur eine Matrix mit rohen Daten hast. Bei Verwendungen einer objektorientierten Programmiersprache hast du durch die unterschiedlichen Paradigmen den sogenannten "Object-Relational Impedance Mismatch".

      Bei Core Data arbeitest du mit einem Objektgraphen, das heißt das du nicht einfach Attributwerte verwaltest, sondern jedes Objekt auch Verhalten hat und du zum Beispiel mit Polymorphie und Kapselung arbeiten kannst. Das kann dazu führen das dein Modell (im MVC) deutlich einfacher zu schreiben, testen und optimieren ist.

      Um zu entscheiden was für Dich am Besten ist würde ich mit dem Datenmodell deiner Anwendung anfangen und nicht mit der Persistenzschicht, die normalerweise nur ein Implementationsdetail ist - es sein denn du bist gerade im Datenbankkurs in der Uni.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von SteveJ ()

    • Core Data: vergesse die Datenbank. Denke in Objekten und deren Beziehungen zueinander. Ohne die Keys. Alles darunter (Speichern, Keys, usw.) besorgt Core Data.

      Du machst keine Joins. Wie oben schon gesagt, suchst Du keine Rezepte mit einer Zutat, sondern die fragst die Zutat, in welchen Rezepten sie verwendet wird. Syntax: zutat.rezepte
      So simpel isses. Das Umdenken erst mal möglicherweise weniger.