Bonjour à tous,
J’ai écouté avec attention le chapitre sur CoreData. Bon chapitre pour mettre le pied à l’étrier et bonne implémentation en séparant la DB du reste. Merci Maxime
Cela a l’air sympa mais avec une modélisation un peu plus complexe et plusieurs entités, rapidement on peut avoir besoin de faire des join, subselect, bref du sql natif.
@Maxime ou qq d’autres qui a pratiqué,
J’ai la sensation que CoreData n’est pas là pour faire du sql natif. Je me trompe ?
Quel serait la bonne alternative pour cela ?
Il peut y avoir une ambiguïté dans la manière dont tu exprimes ton « besoin »:
si ton « besoin » est de gérer des bases de données complexes, de faire des extractions, des tris, etc…, Core Data devrait te permettre de faire tout ça (sans manipuler de SQL)
si ton « besoin » est de « faire du SQL natif », je ne sais pas quel est le meilleur outil
J’avais l’impression que mon post de départ n’est pas ambigu.
SqlNatif dans CoreData ? : oui / non . Tu m’as apporté une réponse et je te remercie.
Si SqlNatif dans CoreData impossible , quelle est l’alternative ?
C’est dans un autre post que j’ai exprimé ma nécessité de pouvoir faire du SQL natif si besoin, en réaction à tu peux utiliser CoreData.
Après, on peut débattre sur la pertinence de faire ou non du SQL natif. Et je trouve cela très intéressant. CoreData de ce que j’en comprend te donne une vision objet de ta base de donnée, et prévoit aussi de gérer des relations oneToMany de façon simple. C’est vrai, et cela correspond à 80% des besoins. C’est très bien.
Mais si tu as besoin de produire des données calculées, des min, max en fonction d’autres éléments, ou bien des outer join par dessus lesquels tu refais une sélection, là CoreData n’est pas adapté, de ce que j’en comprend. Tu vas être obligé de manipuler tes objets, retourner dans la base, voir si tu as de gros volumes, instancier un paquet d’objet pour rien, de façon intermédiaire. Ce ne sont que quelques exemples.
Le plus difficile est finalement de déterminer dès le début si CoreData est. adapté ou non. Encore une fois CoreData est très bien dans la majorité des cas.
Personnellement je n’aime pas du tout CoreData et je trouve le SQL natif plus simple ; mais ça vient du fait que je connais déjà le SQL. En revanche j’aime plus Realm qui me fait gagner du temps et je comprends que @fjacquemin l’ait proposé car il couvre la plupart des besoins avec un code beaucoup plus court que CoreData ou SQLite.
Si tu as vraiment des besoins spécifiques qui ne sont couverts ni par CoreData, ni par Realm alors probablement que le SQLite est la meilleure solution pour toi.
Le seul intérêt que je vois pour toi à utiliser CoreData plutôt que SQL :
J’ai un vague souvenir d’une conférence d’Apple où l’intervenant annonçait que la même app utilisant CoreData était plus performante que SQLite mais je ne me rappelle plus le détails (consommation de RAM, vitesse d’exécution des requêtes, etc.). Il doit y avoir un peu de cache dans CoreData qui permet de limiter les accès SQL répétés probablement. Mais ça reste un souvenir vague d’une conf que j’avais suivi il y a très longtemps donc ça reste à vérifier.
Merci @mbritto et @fjacquemin , j’ai balayé trop vite Realm dans ce cas. J’ai cru à tord que c’était devenu obsolète, puisque Apple pousse CoreData. Du coup, vais retourner voir de quoi il retourne avant de choisir.
Encore merci à tous les deux.
