Core Data versus Datenbank

Core-Data ist eine Art »XML-Datenbank« für Cocoa-Programme, die mit Tiger eingeführt wurde. Es können dabei SQL-ähnliche Abfragen mit NSPredicates und Relationen zwischen den verschiedenen »Objekten« erstellt werden.
Allerdings stellt sich sehr bald die Frage der Vor- und Nachteile gegenüber den herkömmlichen Methoden der Speicherung als Datei (meistens eine oder mehrere Plists), oder in einer Datenbank (PostgreSQL, MySQL …). Und vor allem: die Einträge sind alle in einer XML-Datei gespeichert — wie performant ist diese, wenn viele Daten verwaltet werden müssen?

Vorteile

  • Core Data geht Hand in Hand mit Cocoa-Bindings — man benötigt weniger GlueCode

  • Um die Speicherung und das Wiederherstellen der Daten braucht man sich keine Gedanken zu machen.

  • Daten und Relationen können in in XCode erstellt werden

  • Der Benutzer benötigt keine vorhandene Installation einer Datenbank

  • weniger Klassen und GlueCode, da man die meisten Entities ohne Bearbeitung übernehmen kann

Nachteile

  • Die mit Core Data erstellten Programme stehen nur Nutzern mit Tiger zur Verfügung — dieser wiegt für mich am schwersten

  • Speichermanagement: Die Entities werden beim Starten der Applikation in den Speicher geladen — Datenbankabfragen können dagegen jederzeit released werden.

  • Die Daten in einer SQL-Datenbank stehen auch Webapplikationen o. ä. zur Verfügung.

Generell hat Core Data ein schönes Konzept, welches die Arbeit des Entwicklers erleichtert. Allerdings sind Applikationen, die mit Core Data realisiert sind, nur unter Mac OS X 10.4 oder höher lauffähig, was einige Benutzer ausschliesst.
Über die Performance der einzelnen XML-Datei verglichen mit einer Relationalen Datenbank habe ich bisher leider keinerlei Dokumentation finden können.
Ich denke jedoch, dass sich der Performance-Unterschied erst ab einer grossen Menge von Daten bemerkbar macht.

Letztendlich bleibt die Frage der Datenspeicherung dem Entwickler überlassen — für welches Modell er sich entscheided, hängt dabei dann von den Anforderungen an das Programm ab.


Ähnliche Artikel

Kommentare

  1. Michael schrieb am 25.01.06:1
    Es besteht die Möglichkeit das Speicherformat bei Core Data einzustellen. Als Alternativen zu XML gibt es sqlite und ein Binärformat. Bei sqlite werden die Daten erst on demand geholt, nicht wie bei xml zu Beginn.
  2. Julia schrieb am 27.01.06:2
    Hallo Michael, danke für den Tipp – diese Möglichkeit habe ich in der Dokumentation leider nirgends gefunden. Aber jetzt werde ich mal gezielt suchen und ein wenig mit dem Speicherformat experimentieren ;)
  3. Götz Verdieck schrieb am 1.02.06:3
    Interessant ist doch auch, wie und ob man auch „richtige Datenbanken“ an Core Data bzw. KVO/KVB anpassen kann.
    Serge Cohen hat gerade einen neuen Framwork für MySQL rausgegeben unter: http://sourceforge.net/projects/mysql-cocoa. Ist ganz interessant.
  4. Julia schrieb am 4.02.06:4
    @Götz: Das Framework hatte ich mir auch schon angesehen, und es ist ein sehr guter Ansatz.
    Ich denke, dass Apple Core Data bewusst so konzipiert hat, dass man keine Voraussetzungen für die Installation eines Programmes braucht (ausser Tiger). Dies wäre ja bei MySQL oder anderen nicht gegeben. Natürlich ist es für den Benutzer nicht weiter schlimm, wenn er sich eine Datenbank installieren muss, aber wenn er drei Programme hat, die drei verschiedene Datenbanken verlangen…

    Bindings kann man natürlich auch mit anderen Datenbanken nutzen, sofern man KVC für die entsprechenden Daten einbaut.

Dein Kommentar:

Sämtliche Html-Tags werden gelöscht, der Kommentar kann mit Textile formatiert werden.
Vor dem Absenden müsst ihr euch einmal die Vorschau ansehen.