›

coreData ou SQL ?

bluholmbluholm Membre
dans Apple Developer Programs #1
Bonjour,

je surf et navigue régulièrement sur votre forum en y trouvant de nombreuse réponse a mes questions !alors c'est parti a mon tour d'en poser ^^



je cherche a déporter notre logiciel interne de société du php/SQL vers mac directement image/wink.png' class='bbc_emoticon' alt=';)' /> pour des raisons de rapidité et aussi de fiabilité...



en gros c'est une application pour mes commerciaux ( qui disposent d'imac) de se connecter sur cette application et d'accéder aux clients (ajouter,modifier,supprimer...) tout les macs se connecte donc a la meme base de données qu'il modifie a leurs guises.



j'ai debuter l'objective c et coca il y a peu et avance a l'aide de tuto et de bouquin que je me suis acheter cependant certaines choses m'interpelle encore, et avant de lancer l'exportation , je souhaitais savoir :





1) quel est la grosse différence entre coreData et Sql ? lequel correspond le mieux a mon projet ?

2) ou vais-je devoir stocker cette base de données pour que tout les postes puisse y accéder ?



merci d'avance !

Réponses

  • muqaddarmuqaddar Administrateur
    #2
    CoreData est un "moteur tout prêt" qui interroge la base de données SQLite, et facilite le travail de questions/réponses avec la base de données: par contre il faut apprendre à  l'interroger...



    Pour ce que tu décris, je vois :

    - une machine serveur avec une base de données SQL accessible en local ou via le web

    - une application cocoa sur les imacs qui utilisent des WebServices et attaquent la base de données principale du serveur OU attaquent directement la base SQL du serveur (je ne sais pas si MySQL Cocoa permet l'accès par réseau ?)



    C'est beaucoup de travail. Il faudra p-e aussi gérer la synchronisation des données et ce qu'il se passe si plusieurs commerciaux font des accès concurrents aux données de la base...
  • ThibautThibaut Membre
    #3
    'muqaddar' a écrit:


    CoreData est un "moteur tout prêt" qui interroge la base de données SQLite, et facilite le travail de questions/réponses avec la base de données: par contre il faut apprendre à  l'interroger...




    Pour être un tout petit peu plus précis :

    Core Data est un gestionnaire de données, qui travaille avec son propre format de base de donnée. Cette base peut être en SQLite mais également en XML (Mac uniquement) ou binaire. Core Data ne peut pas fonctionner avec une base de données classique.
  • muqaddarmuqaddar Administrateur
    #4
    Je ne savais pas que CoreData pouvait s'interfacer avec un fichier XML.
  • CéroceCéroce Membre, Modérateur
    #5
    La BdD est bien au format SQLite (en interne), mais on peut l'enregistrer au format XML (ou même dans un format personnalisé). Apple précise clairement que le format XML est conçu pour le débogage; ça permet de voir que les enregistrements se sont exécutés. Mais ce n'est pas conçu pour s'interfacer.
  • RocouRocou Membre
    #6
    Pour ma part, j'utilise PostgreSQL; le moteur est d'ailleurs maintenant intégré à  OSX.

    Il est pratique d'utiliser un "Framework" spécialisé pour accéder à  la base via une application Mac. J'utilise le PGSQLKit de Andy Satory mais on peut également attaquer la base à  l'aide d'une "lib" C.



    Cela n'a rien de difficile, cela fonctionne remarquablement bien. J'ai développé, avec l'aide des membres du forum car je débutais, plusieurs applications et notamment une gestion de location de conteneurs, multi utilisateur avec accès simultanés ainsi qu'une application de gestion de collecte de déchets.



    En ce moment, un développeur indépendant* me concocte une application iPhone qui se connectera sur la base (via un web service).



    Il me semble que CoreData n'est pas multi-utilisateur.



    *Connu grâce au service annonces pro du forum, merci encore encore muqaddar.
  • muqaddarmuqaddar Administrateur
    #7
    'Rocou' a écrit:


    *Connu grâce au service annonces pro du forum, merci encore encore muqaddar.




    1) C'est le troisième retour positif que j'ai, je suis content de voir que ça peut être efficace.



    2) J'ai souvent entendu du bien de PostgreSQL... mais je suis resté en MySQL.



    3) Pour ma part, j'aime bien utiliser le SQL pour plusieurs raisons:



    1- Les requêtes un peu complexes ne me gênent pas et j'y vois clair si il faut optimiser...

    2- Dans une approche client/serveur, il peut être intéressant d'utiliser du SQL partout plutôt que CoreData sur le client: par exemple, j'ai tapé des requêtes complexes sur le client et j'aurais pratiquement les mêmes sur le serveur => dans tous les cas, j'aurais eu à  les saisir sur le serveur.

    3-D'autre part, si un jour votre/mon appli client est portée sur une autre plateforme, on sait que le SQL sera disponible, contrairement à  CoreData.
Connectez-vous ou Inscrivez-vous pour répondre.