Core Data vs. SQLite für SQL-erfahrene Entwickler

Question

Wir beginnen mit der Entwicklung einer eigenen App im Rahmen des iPhone Enterprise Entwicklerprogramms. Da wir kurz vor OS 3.0 stehen, überdenken wir unseren ursprünglichen Plan, SQLite zu verwenden, und setzen stattdessen Core Data ein. Hier sind einige weitere Informationen:

• Es gibt eine alte Desktop-Anwendung, die dadurch ersetzt wird. Wir werden das bestehende Backend wiederverwenden.
• Wir haben derzeit eine SQLite-Datenbank als Proof of Concept erstellt. Dies ist im Grunde eine abgespeckte Version der bestehenden Backend-Datenbank.
• Wir werden Daten von einem entfernten Standort laden und sie lokal speichern, wo sie bestehen bleiben und gespeichert werden müssen. Wir aktualisieren sie nur, wenn sie sich geändert haben, was alle ein bis zwei Monate der Fall sein wird. Wir werden höchstwahrscheinlich XML oder JSON verwenden, um die Daten zu übertragen.
• An diesem Projekt sind zwei Entwickler beteiligt, die beide über gute SQL-Kenntnisse verfügen, aber keiner von ihnen hat Core Data verwendet.

Meine Fragen lauten: Was ist der Vorteil von Core Data gegenüber SQLite, was wäre der Vorteil in diesem speziellen Fall, und rechtfertigen die Vorteile das Erlernen eines neuen Frameworks anstelle der Nutzung vorhandener starker SQL-Kenntnisse?

EDIT: Diese Frage ist mir gerade aufgefallen: Core Data gegenüber SQLite 3 . Ich schätze, meine Fragen sind daher:

• Wenn ich prüfen muss, ob ein bestimmtes Element entweder existiert oder aktualisiert wurde, was mit SQL leicht möglich ist, ist Core Data dann noch sinnvoll? Kann ich das erste Objekt in einem Diagramm laden und die Versionsnummer überprüfen, ohne das gesamte Diagramm zu laden?
• Wenn wir bereits SQL kennen, rechtfertigen dann die Vorteile von Core Data für dieses eine Projekt, dass wir es lernen?

Answer 1

Wie Sie gelesen haben Core Data gegenüber SQLite 3 wissen Sie, dass Core Data und der Persistenzmechanismus (in diesem Fall SQLite) weitgehend orthogonal sind. Bei Core Data geht es eigentlich um die Verwaltung eines Objektgraphen, und sein Hauptanwendungsfall ist die Modellkomponente einer MVC-Architektur. Wenn Wenn Ihre Anwendung gut in diese Architektur passt, lohnt es sich wahrscheinlich, Core Data zu verwenden, da Sie dadurch eine Menge Code in der Modellkomponente einsparen können. Wenn Sie bereits eine funktionierende Modellkomponente haben (z. B. aus der bestehenden Desktop-Anwendung), dann bringt Core Data Ihnen nicht viel. Ein hybrider Ansatz ist möglich - Sie können Ihre eigene Persistenz/Abfrage durchführen und einen Core Data In-Memory-Speicher erstellen, den Sie mit dem Ergebnis einer Abfrage befüllen und diesen In-Memory-Speicher über Core Data als Modellkomponente für Ihre Anwendung verwenden. Dies ist nicht üblich, aber ich habe es getan und es gibt keine größeren Hindernisse.

Um Ihre spezifischen Fragen zu beantworten:

1. Sie können dem gesamten persistenten Speicher eine Versionsnummer zuweisen und diese Informationen über +[NSPersistentStore metadataForPersistentStoreWithURL:error:] ohne den Laden überhaupt zu öffnen. Ein Äquivalent +setMetadata:forPersistentStoreWithURL:error gibt es natürlich auch. Wenn Sie die Versionsinformationen nicht in den Metadaten des persistenten Speichers, sondern in einer Entitätsinstanz speichern wollen, können Sie nur ein einziges Objekt laden. Mit einem SQLite-Persistenzspeicher ist Core Data sehr gut in der Lage, nur das abzurufen, was Sie benötigen.

2. En NSPredicate API, ist sehr leicht zu erlernen und scheint eine gute Arbeit bei der Kompilierung zu SQL zu leisten. Zumindest für Datenbanken, die so groß sind, dass sie auf ein iPhone passen, ist es meiner Erfahrung nach angemessen (was die Leistung angeht). Die Frage SQL vs. Core Data ist meiner Meinung nach jedoch nicht ganz richtig gestellt. Was machen Sie mit dem Ergebnis einer Abfrage, sobald Sie es haben? Wenn Sie Ihre eigene Lösung entwickeln, müssen Sie Objekte instanziieren, mit Faulting/Uniqueing umgehen (wenn Sie nicht sofort das gesamte Ergebnis einer Abfrage in den Speicher laden wollen) und all die anderen Möglichkeiten zur Verwaltung des Objektgraphen nutzen, die Core Data bereits bietet.

Answer 2

Es hört sich so an, als hätten Sie das Projekt bereits mit SQLite entworfen und hätten Erfahrung auf diesem Gebiet.

Unterm Strich stellt sich also die Frage, ob es sinnvoll ist, dieses Projekt zu portieren, und ob Core Data mir etwas bietet, was ich nicht schon in meinem ursprünglichen Entwurf hatte.

Wenn man davon ausgeht, dass der ursprüngliche Entwurf ordnungsgemäß ausgeführt wurde, lohnt es sich auf der Grundlage der Anforderungen an dieses Projekt wahrscheinlich nicht.

Aber damit ist die Diskussion noch nicht zu Ende. Es gibt noch andere Dinge, über die man nachdenken muss: Wird mein nächstes Projekt so geringe Datenbankanforderungen haben? Muss ich aufgrund von Zeit- oder Budgetbeschränkungen bald liefern? Wenn ich davon ausgehe, dass ich früher oder später Core Data lernen muss, macht es dann nicht Sinn, es jetzt zu tun? Bin ich möglicherweise daran interessiert, meinen Code auf den Mac zu portieren?

Die Antworten auf diese Fragen könnten Sie zu der Entscheidung führen, dass es sich in der Tat lohnt, sozusagen zurück ans Reißbrett zu gehen und zu lernen, was es mit den Kerndaten auf sich hat.

Um auf Ihre letzte Frage einzugehen: Was sind die Vorteile? Nun, Core Data ist eine höhere Abstraktionsebene Ihrer Datenbank und ist auch unabhängig vom Datenspeicher (wenn also eine zukünftige Version des iPhones SQLite durch eine eingebettete Version von MySQL ersetzen würde... unwahrscheinlich, aber es ist ein Beispiel), dann würde Core Data SEHR wenige Änderungen am Code erfordern, damit es mit dem neuen Datenspeicher funktioniert. Core Data wird eine sehr schnelle Portabilität auf die Mac-Plattform ermöglichen. Core Data übernimmt die Versionierung Ihres Datenmodells, wohingegen der direkte Zugriff auf SQLite nicht möglich ist, es sei denn, Sie haben ein Framework oder einen Workflow, um dies zu verwalten.

Ich bin mir sicher, dass andere Beantworter andere Vorteile nennen können und vielleicht auch gute Gründe, warum man sich NICHT mit Core Data anlegen sollte. Übrigens habe ich mich in einer ähnlichen Situation für die Portierung auf das neuere Framework entschieden. In meinem Fall handelte es sich jedoch um ein Nebenprojekt, bei dem Liefertermin und Budget keine Rolle spielten.

Answer 3

Ich möchte nicht von diesem Forum ablenken, aber vielleicht finden Sie im Apple iPhone DevForum mehr Teilnehmer mit einschlägiger Erfahrung.

Aus einer reinen Projektmanagement-Perspektive hört es sich so an, als wüssten Sie, wie Sie das, was Sie erstellen wollen, mit SQLite erstellen können, und daher würde es für Sie mehr Sinn machen, diesen Weg einzuschlagen.

Allerdings baut CoreData auf SQLite auf, und wenn Sie versuchen, andere Teile des Systems in Verbindung mit Ihren Daten zu nutzen, z. B. mit KVC/KVO oder Bindungen, dann werden Sie schnell feststellen, dass diese Funktionalität die Lernkurve wert ist.

\= Mike