Core Data VS Sqlite ou FMDB.... ?

Question

Maintenant, cela peut sembler être un fil de discussion en double, mais ma question est que j'ai lu beaucoup de questions comme Core Data vs SQLite 3 et d'autres, mais ils datent de 2 ou 3 ans. J'ai également lu que FMDB a été développé car core data n'était pas supporté sur iOS, il ne devrait donc plus être utilisé. Et d'autre part, j'ai lu que l'on ne devrait pas utiliser core data comme base de données.

Je suis donc très confus, je ne sais pas si je dois utiliser les données de base pour le stockage des objets ou non. . Je veux dire sur quelle base je dois décider lequel utiliser ? Existe-t-il des directives fournies par Apple ou quelqu'un d'autre ou est-ce quelque chose qui me viendra avec le temps ?

Answer 1

Ankit,

Voici le résumé : utilisez les données de base.

Voici la version longue :

Bien que vous puissiez utiliser de nombreux critères pour choisir entre Core Data, un ORM (FMDB) ou des appels sqlite directs, le coût réel de ce choix provient du temps que vous consacrez à son utilisation, du support d'Apple et de l'effet de levier d'autres projets. (RESTKit, qui mappe les services REST sur Core Data, est populaire ces jours-ci).

Par conséquent, dans un grand pourcentage de cas, disons 90+% (une statistique inventée), la réponse sur iOS sera d'utiliser Core Data. Pourquoi ? Une fois que vous aurez pris le coup de main et développé quelques petites méthodes d'aide, Core Data vous maintiendra dans un monde informatique cohérent : le graphe objet d'Objective-C. Core Data vous apprendra des choses sur la façon d'utiliser un langage dynamique qui vous aideront dans tous les autres aspects de votre programmation iOS. Vous serez donc plus productif. Ne vous battez pas contre le framework.

Si vous transférez une base de données et un schéma SQLite complexes et volumineux d'une autre application, il pourrait être rentable d'utiliser FMDB ou SQLite. Mais j'en doute. Le temps que vous consacrez à écrire une simple application Mac en ligne de commande pour migrer la base de données vers une base de données Core Data est une tâche simple et limitée. Vous êtes presque sûr de devoir réécrire la plupart de la logique métier en Objective-C. (Oui, C++ et Objective-C++ sont deux bonnes technologies. La logique métier de votre base de données a-t-elle vraiment été réglée pour fonctionner sur un appareil à mémoire limitée ? Je ne le pensais pas).

Les performances de Core Data sont malmenées. Il est en fait très rapide. Il faut simplement l'utiliser différemment d'une base de données. En particulier, vous récupérez presque toujours trop de données dans le magasin, puis vous les affinez en utilisant des prédicats directement sur les différents ensembles et tableaux. Sur les appareils iOS, où la mémoire flash est étonnamment lente, cette stratégie de sur-recherche est particulièrement efficace. Vous disposez en fait de beaucoup de RAM sur ces appareils, utilisez-la pour gagner en performance. (Oui, je sais que c'est une contradiction apparente avec mon coup de gueule ci-dessus sur la logique d'entreprise portable. Mais vraiment, le code porté depuis un environnement de bureau ou de serveur a tellement d'hypothèses implicites sur la vitesse du disque, la quantité de mémoire et la réalité d'une VM avec un backing store, qu'il ne fonctionnera tout simplement pas bien sur un appareil alimenté par une batterie, à la mémoire limitée et au modèle de mémoire funky. [Vous dénormaliserez également vos données afin de simplifier leur affichage dans divers widgets d'interface utilisateur iOS et Mac OS X. Il y a quelques applications où Core Data sera plus lent qu'une BD SQLite équivalente. Elles ont été détaillées ailleurs. La seule affirmation majeure est que les tâches où les ID sont définis par des bases de données en amont affectent les performances de Core Data, ce qui est vrai. Mais cela peut être quelque peu atténué par une indexation judicieuse et une recherche excessive.

Ce qu'il faut retenir aussi des appareils mobiles, c'est que la taille de la base de données, parce qu'il s'agit d'appareils mobiles sur les feuilles de l'internet, est généralement de taille modeste. Les performances sont donc plus faciles à atteindre. De nombreuses leçons tirées du monde des serveurs peuvent ne pas s'appliquer à ce monde mobile, alimenté par des batteries.

En d'autres termes, si vous avez dû vous lancer à fond dans l'utilisation d'Objective-C sur iOS/Mac OS X, l'utilisation de Core Data vous apportera également des avantages importants en termes de productivité.

Andrew

Answer 2

Je me suis récemment lancée dans cette aventure et j'ai fini par essayer les trois. Voici ce que j'ai appris :

• Raw sqlite3
  • Bas niveau, accès complet à la base de données. Pas d'abstractions. Très verbeux - il faut beaucoup de code pour faire des choses très simples.
• Données de base
  • Très haut niveau, construit sur des abstractions, DOIT utiliser la base de données générée par Apple. Utile pour la synchronisation iCloud et la gestion simple des données uniquement sur iOS. Difficile et dangereux d'accéder directement à la base de données, et ne devrait pas être utilisé pour les bases de données multiplateformes. Nécessite toujours une bonne quantité de code pour faire des choses simples.
• FMDB
  • Haut niveau, très facile à abstraire, mais pas forcé. Vous avez toujours un accès complet à la base de données si vous en avez besoin. Fournit un NSDictionary du résultat, chaque élément étant automatiquement typographié dans la variante mutable du type de données approprié (par exemple, les colonnes de texte sont renvoyées sous forme de NSMutableString ). J'ai fini par construire une classe d'enveloppe très simple autour d'elle pour la rendre encore plus abstraite. J'ai donc une classe d'aide avec des fonctions statiques telles que selectAllFrom:(NSString *)table where:(NSDictionary *)conditions qui renvoie un NSArray de NSDictionary des objets. C'est fantastique de pouvoir faire des choses comme NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}]; .

En gros, si Core Data peut être utile pour les applications simples réservées à iOS, toute personne souhaitant utiliser des bases de données multiplateformes devrait s'en tenir très, très loin. Apple n'a aucun intérêt à rendre cela facile, et cela se voit.

---

TL;DR :

• N'utilisez pas sqlite3 brut, sauf si vous faites quelque chose d'extrêmement trivial.
• Core Data convient parfaitement pour les données simples réservées à iOS, si vous n'avez pas peur d'y être enfermé.
• Si vous voulez un contrôle total de la base de données et que vous ne faites pas quelque chose de trivial, ou si vous construisez votre application pour plusieurs plates-formes, FMDB est définitivement la voie à suivre.

Answer 3

J'utilise FMDB pour tous mes projets qui font un usage intensif de " INSERT s" et la FMDB n'est pas dépassée. Le dernier commit sur Github date de novembre dernier. Si vous optez pour SQL, je vous recommande d'utiliser FMDB.

Core Data convient à 95% de tous les projets, mais s'il s'agit d'optimisation, il faut courir vers un mur. Si vous voulez bénéficier des avantages de Core Data (OOP, ...), utilisez-le. Si vous avez beaucoup d'insertions et de suppressions avec " WHERE "utilisateur Sqlite (FMDB)

Ce site POST expliquer le site off et top pour Core Date vs. Sqlite (FMDB)

Answer 4

CoreData est pas juste une abstraction d'une base de données SQL. CoreData permet également de gérer les graphes d'objets. CoreData peut faire des choses que FMDB ne peut tout simplement pas faire.

Comme toujours : Cela dépend vraiment de votre cas d'utilisation. Mais dans 99 % des cas, CoreData est le bon choix.

Si les performances sont essentielles, vous devez quand même comprendre le fonctionnement d'une base de données. Mais CoreData peut offrir ces performances si vous l'utilisez de la bonne manière. Mais l'apprentissage prend du temps. Il y a beaucoup de choses qui sont triviales à faire dans CoreData et qui seraient très complexes à faire dans FMDB.

Answer 5

Core Data n'est qu'une abstraction d'objet de la base de données SQLite3. Cela signifie que vous aurez des objets persistants faciles à gérer pour les opérations de base de données standard. Vous pouvez également travailler en mode transactionnel et concevoir la structure de votre base de données Core Data dans XCode en créant des modèles.

Si vous ne voulez pas créer manuellement votre base de données SQLite3 ou vos méthodes persistantes, utilisez Core Data.