Core Data vs. SQLite pour les développeurs expérimentés en SQL

Question

Nous commençons le développement d'une application interne dans le cadre du programme de développement iPhone Enterprise. Comme nous sommes proches de la version 3.0 de l'OS, nous reconsidérons notre projet initial d'utiliser SQLite et utilisons Core Data à la place. Voici quelques informations supplémentaires :

• Il s'agit de remplacer une ancienne application de bureau. Nous réutiliserons le back-end existant.
• Nous avons actuellement une base de données SQLite générée comme preuve de concept. Il s'agit essentiellement d'une version réduite de la base de données dorsale existante.
• Nous allons charger des données à partir d'un site distant et les stocker localement, où elles persisteront et devront être mises à jour. Nous ne les mettrons à jour que si elles ont changé, c'est-à-dire tous les mois ou tous les deux mois. Nous utiliserons très probablement XML ou JSON pour transférer les données.
• Deux développeurs travaillent sur ce projet et nous avons tous deux de solides compétences en SQL, mais aucun n'a utilisé Core Data.

Mes questions sont les suivantes : quel est l'avantage de Core Data par rapport à SQLite, quel serait l'avantage dans ce cas spécifique et est-ce que les avantages justifient l'apprentissage d'un nouveau cadre au lieu d'utiliser les solides compétences SQL existantes ?

EDIT : Je viens de remarquer cette question : Core Data vs SQLite 3 . Je suppose que mes questions sont donc les suivantes :

• Si je dois vérifier si un élément spécifique existe ou a été mis à jour, ce qui est facile en utilisant SQL, est-ce que Core Data a encore un sens ? Puis-je charger le premier objet d'un graphique et vérifier le numéro de version sans charger tout le graphique ?
• Si nous connaissons déjà SQL, les avantages de Core Data pour ce seul projet justifient-ils que nous l'apprenions ?

Answer 1

Comme vous l'avez lu Core Data vs SQLite 3 vous savez que Core Data et le mécanisme de persistance (SQLite dans ce cas) sont largement orthogonaux. Core Data consiste en fait à gérer un graphe d'objets et son principal cas d'utilisation est le composant modèle d'une architecture MVC. Si votre application s'inscrit parfaitement dans cette architecture, il est probablement intéressant d'utiliser Core Data car cela vous permettra d'économiser beaucoup de code dans le composant modèle. Si vous avez déjà un composant de modèle fonctionnel (par exemple, à partir de l'application de bureau existante), alors Core Data ne vous apportera pas grand-chose. Une approche hybride est possible - vous pouvez faire votre propre persistance/interrogation et construire un magasin Core Data en mémoire que vous alimentez avec le résultat d'une requête et utiliser ce magasin en mémoire via Core Data comme composant de modèle pour votre application. Ce n'est pas courant, mais je l'ai fait et il n'y a pas d'obstacles majeurs.

Pour répondre à vos questions spécifiques :

1. Vous pouvez attribuer un numéro de version à l'ensemble du magasin persistant et récupérer cette information via +[NSPersistentStore metadataForPersistentStoreWithURL:error:] sans même ouvrir le magasin. Un équivalent +setMetadata:forPersistentStoreWithURL:error existe aussi, bien sûr. Si vous souhaitez stocker les informations de version dans une instance d'entité plutôt que dans les métadonnées du magasin persistant, vous ne pouvez charger qu'un seul objet. Avec un magasin persistant SQLite, Core Data fait un très bon travail en récupérant uniquement ce dont vous avez besoin.

2. En NSPredicate est très facile à apprendre et semble faire un bon travail de compilation en SQL. Au moins pour les bases de données de la taille d'un iPhone, il s'est avéré adéquat (en termes de performances) selon mon expérience. Cependant, je pense que la question SQL vs. Core Data est légèrement erronée. Une fois que vous avez obtenu le résultat d'une requête, qu'allez-vous en faire ? Si vous vous débrouillez tout seul, vous devrez instancier des objets, gérer le faulting/uniqueing (si vous ne voulez pas charger immédiatement en mémoire le résultat entier d'une requête) et toutes les autres facilités de gestion du graphe d'objets déjà fournies par Core Data.

Answer 2

Il semble que vous ayez déjà conçu le projet en utilisant SQLite, et que vous ayez de l'expérience dans ce domaine.

La question est donc de savoir s'il est judicieux de porter ce projet, si Core Data va m'apporter quelque chose que je n'avais pas déjà dans ma conception initiale.

En supposant que la conception originale a été faite correctement, sur la base des exigences de ce projet, cela ne vaut probablement pas la peine.

Mais ce n'est pas la fin de la discussion. Il y a d'autres choses auxquelles il faut penser : Mon prochain projet aura-t-il des exigences aussi légères en matière de base de données ? Ai-je besoin de livrer rapidement, en raison de contraintes de temps ou de budget ? En supposant que je doive apprendre Core Data tôt ou tard, n'est-il pas judicieux de le faire maintenant ? Suis-je intéressé par le portage de mon code sur le Mac ?

Les réponses à ces questions peuvent vous amener à décider que, oui, cela vaut la peine de retourner à la planche à dessin, pour ainsi dire, et d'apprendre ce que sont les données de base.

Pour en venir à votre dernière question : Quels sont les avantages ? Eh bien, Core Data est une abstraction de plus haut niveau de votre base de données, il est également agnostique de magasin de données (donc si une future version de l'iPhone devait abandonner SQLite pour une version intégrée de MySQL... peu probable, mais c'est un exemple) alors Core Data exigerait TRES peu de changements au code pour le faire fonctionner avec le nouveau magasin de données. Core Data fournira une grande quantité de portabilité rapide à la plate-forme Mac. Core Data gérera le versionnage de votre modèle de données, alors qu'à moins d'avoir un cadre ou un flux de travail pour le gérer, l'accès direct à SQLite ne le fera pas.

Je suis sûr que d'autres personnes pourront proposer d'autres avantages, et peut-être de bonnes raisons de ne PAS toucher aux données de base. Par ailleurs, dans une situation similaire, j'ai décidé de porter mon projet vers un framework plus récent et de plus haut niveau. Mais dans mon cas, il s'agissait d'un projet secondaire, et la date de livraison et le budget n'étaient pas des facteurs déterminants.

Answer 3

Sans vouloir détourner l'attention de ce forum, vous trouverez peut-être plus de personnes ayant une expérience pertinente dans le contexte du DevForum de l'iPhone d'Apple.

D'un point de vue purement gestion de projet, il semble que vous sachiez comment construire ce que vous voulez construire en utilisant SQLite, et il serait donc plus logique pour vous de commencer par cette voie.

Ceci étant dit, CoreData s'appuie sur SQLite et si vous essayez d'exploiter d'autres parties du système en conjonction avec vos données, par exemple en utilisant KVC/KVO ou des liaisons, vous constaterez rapidement que cette fonctionnalité vaut la peine d'être apprise.

\= Mike