Base de données en ligne

Bonjour à  tous,


 


Je vais poser une question très large aujourd'hui et qui possède surement beaucoup de solutions différentes. Aujourd'hui je sais me servir d'une base de données local qui est stockée sur l'appareil de l'utilisateur. Je sais aller chercher des données dans une BDD de type SQLite3 en utilisant le framework adéquate ou en utilisant plus simplement CoreData que je trouve vraiment très bien fait et surtout très simple à  utiliser.


Mais maintenant j'aimerais aller plus loin et aller chercher des données stockées sur un serveur. Ma question est : comment puis-je faire pour aller chercher ces données stockées sur un serveur ?


 


Pour décomposer un peu plus ma question, en fait, je ne sais pas du tout par où commencer, où aller regarder, si il existes des tutoriels simples etc. J'ai vraiment fait beaucoup de recherche sur Google mais impossible d'avoir une réponse nette et précise à  ce sujet.


 


Donc je m'adresse à  vous pour essayer d'avoir plus de renseignements à  ce sujet parce que vraiment ce sujet c'est vraiment le noir absolu pour moi et je ne sais absolument rien à  propos de cela...


 


J'espère que j'ai été compréhensible dans mes questions et que vous pourrez éclairer ma lanterne.


 


Merci d'avance :)


«1

Réponses

  • AliGatorAliGator Membre, Modérateur

    On a déjà  répondu plusieurs fois à  la quesiton, il te faut donc juste les bons mots clés pour ta recherche.


     


    En particulier la solution est de développer un petit WebService sur ton serveur, qui va exposer l'accès à  ta base via un service JSON par exemple (ou XML ou autre), et ton appli iPhone va appeler ce WebService (requête HTTP) qui va te répondre avec du JSON pour te décrire les objets. Tu pourras alors recréer des objets modèle (CoreData ou autre) à  partir de ces JSON.


     


    Après, tu as des solutions plus poussées ou encapsulant déjà  certaines parties. Développer le WebService (en PHP ou Ruby ou ce que tu préfères) côté serveur pour s'interfacer avec ta base MySQL restera de ta responsabilité, mais pour parser le JSON reçu côté iPhone pour le transformer en objets CoreData ou métier tu peux sans doute utiliser des frameworks tout faits si tu as l'occasion de creuser un peu ce sujet.


     


    Par exemple  @yoann va sans doute te parler de son framework ObjectiveREST, ou sinon avec CoreData plutôt qu'un PersistentStore classique tu peux utiliser les NSIncrementalStore (par exemple si tu utilises AFNetworking, Mattt a fait AFIncrementalStore pour ça. Perso je n'ai encore eu l'occasion d'utiliser ni l'un ni l'autre, mais ça me semble intéressant quand même.


  • Tu as besoin d'un serveur sur lequel stocker ta base de donnée.

    Tu peux louer un serveur nu ou un espace pré-configuré dédié ou mutualisé.

    Après tu as besoin d'un langage sur ton serveur pour accéder à  ta base de donnée (php, ruby, python).

    Le grand classique c'est php+mysql.


    Si tu n'y connais rien, il vaut mieux se diriger vers un serveur mutualisé où php et mysql seront préinstallés.


    Si tu as déjà  une base SQLite3, j'imagine que tu peux y accéder dans les mêmes langages mais ça va être plus compliqué. Il vaut mieux trouver un moyen d'exporter ta base pour la ré-importer sur mysql.



    Je suis en train de travailler sur un framework en objective-C côté serveur où on pourra utiliser CoreData (quelques samples ici). Mais cela reste une solution très captive, puisque tu as besoin d'un serveur qui soit un mac.

     


  • Merci à  vous deux pour vos réponses c'est désormais un peu plus clair dans ma tête merci beaucoup !


     


    Donc comme dit AliGator je vais pouvoir désormais faire des recherches un peu plus poussées grâce aux mots clés donnés dans tes explications.


     


    Merci aussi FKDEV mais pour être bien sûr, en fait, je communique avec le serveur avec un langage spécifique (par exemple le php) ? C'est de cette façon que je lui dit ma requête ?


  • AliGatorAliGator Membre, Modérateur
    septembre 2013 modifié #5

    Merci aussi FKDEV mais pour être bien sûr, en fait, je communique avec le serveur avec un langage spécifique (par exemple le php) ? C'est de cette façon que je lui dit ma requête ?

    Non. PHP est le langage côté serveur, c'est pas du tout un truc qui va tourner sur ton iPhone.

    - Côté iPhone tu codes toujours en Objective-C.
    - Via du code ObjC, genre en utilisant NSURLRequest & co, tu fais une requête vers http://tonserveur.org/blabla/truc.php par exemple.
    - Sur le serveur, truc.php est un fichier écrit en PHP qui va se charger de se connecter à  ta base MySQL, récupérer les données que tu lui demandes, et générer une représentation JSON (ou XML ou autre, comme tu veux) de ces données extraites de la BDD, pour te les retourner.
    - Du coup ton code Objective-C sur l'iPhone reçoit ce JSON en réponse à  sa requête et il ne te reste plus qu'à  parser ce JSON (avec du code Objective-C) et construire tes objets modèle correspondants.



    Un exemple de WebService existant, celui de Wikipedia. Si tu veux le contenu de l'article ayant pour titre "Cocoa", peux envoyer la requête http://fr.wikipedia.org/w/api.php?format=json&action=query&titles=Cocoa&prop=extracts qui va aller chercher dans leur base de données le bon article et son contenu, et te retourner une représentation JSON.
    Si tu voulais faire une appli iPhone qui permet d'afficher des articles Wikipedia, il suffit d'envoyer cette requête (via NSURLRequest, NSURLConnection, ...), récupérer le JSON retourné, et en faire ce que tu veux dans ton code Objective-C.

    Bah dans ton cas c'est pareil, sauf qu'il va falloir que tu codes toi-même le WebService (donc le script PHP équivalent à  api.php de Wikipedia) que tu vas mettre sur ton serveur.

    Renseigne toi sur le terme de WebService (sur Google comme sur les Forums) on a déjà  pas mal couvert le sujet.
  • BenjoBenjo Membre
    septembre 2013 modifié #6

    Ok super AliGator pour ses explications c'est vraiment génial. Donc il va falloir que je me mette au PHP si je veux m'aventurer là  dedans. Donc je vais aller regarder plus précisément sur internet. Merci beaucoup !


  • colas_colas_ Membre
    septembre 2013 modifié #7

    J'ai un peu regardé l'hébergement de base de donnée (bdd) online, et j'ai vu qu'il y avait deux cas : 


    1) une base interrogeable de l'extérieur


    2) une base liée à  un hébergement de site web


     


    Je croyais que pour lier une app à  un bdd, il fallait passer par 2) mais vu qu'on peut faire passer notre requête via le protocole http, on peut passer par 1) " et ce n'est pas considéré comme un hacking. La page .php, au lieu de générer un fichier html va donc générer un fichier JSON.


     


    Est-il facile pour un hacker de voir les requêtes http qu'envoie une application (ou un iApp) ?


  • AliGatorAliGator Membre, Modérateur
    Oui très facile d'ecouter ce qui passe sur HTTP.

    Si tu veux protéger tes données, passe par HTTPS pour communiquer avec ton serveur, et un mécanisme d'authentification.


  • Par exemple  @yoann va sans doute te parler de son framework ObjectiveREST, ou sinon avec CoreData plutôt qu'un PersistentStore classique tu peux utiliser les NSIncrementalStore (par exemple si tu utilises AFNetworking, Mattt a fait AFIncrementalStore pour ça. Perso je n'ai encore eu l'occasion d'utiliser ni l'un ni l'autre, mais ça me semble intéressant quand même.




     


    Attention, ObjectiveREST n'est qu'un PoC. Il fonctionne mais ça reste un PoC.


     


    Depuis je travail sur le projet StarDAV.com avec des amis, on est un peu à  la bourre sur la beta, mais on a un framework de synchro CoreData à  la iCloud sur n'importe quel serveur WebDAV (à  base de NSIncrementalStore).

  • J'ai un peu regardé l'hébergement de base de donnée (bdd) online, et j'ai vu qu'il y avait deux cas : 

    1) une base interrogeable de l'extérieur

    2) une base liée à  un hébergement de site web

     

    Je croyais que pour lier une app à  un bdd, il fallait passer par 2) mais vu qu'on peut faire passer notre requête via le protocole http, on peut passer par 1) " et ce n'est pas considéré comme un hacking. La page .php, au lieu de générer un fichier html va donc générer un fichier JSON.




    Je ne vois pas trop la difference entre 1 et 2.

    Qu'appelles tu une base interrogeable à  distance ? As tu un exemple ?
  • colas_colas_ Membre
    septembre 2013 modifié #11

    @FKDEV


    Je n'ai pas trop d'exemple mais dans ma courte expérience en entreprise, on se connectait aux bdd (Oracle) sans passer par des requêtes HTTP, on avait des commandes en ligne ou on utilisait un logiciel (Toad).


     


    --> Ainsi, j'imaginais que depuis mon app j'aurais pu utiliser un framework me permettant de faire une requête directement sur ma bdd.


     


    Sinon, j'ai aussi lu quelque chose de vague qui se rapporte à  cela : essaye de googleiser 



    "En effet, je crois aussi que OVH ne laisse pas les serveurs externes au réseau OVH se connecter à  leurs bases de données."

    avec les guillemets !


     


     


    Peut-on utiliser un hébergement gratuit ?


    Comment sinon choisir son hébergeur ?


     


     


    @yann : PoC ça veut dire "démo" ?


  • CéroceCéroce Membre, Modérateur
    septembre 2013 modifié #12

    Sinon, j'ai aussi lu quelque chose de vague qui se rapporte à  cela : 

    "En effet, je crois aussi que OVH ne laisse pas les serveurs externes au réseau OVH se connecter à  leurs bases de données."

    Comme expliqué plein de fois, les hébergeurs sérieux permettent uniquement au serveur qui héberge la BdD de se connecter à  celle-ci, pour des raisons de sécurité. Sinon, ce serait trop simple: on trouve le mot de passe par force brute, et c'est la grosse fête.
     

    Peut-on utiliser un hébergement gratuit ?

    Si tu en trouves un qui héberge une BdD et qui permet l'utilisation d'un langage de script, oui... mais ne rêve pas trop.
     

    Comment sinon choisir son hébergeur ?

    Un hébergement avec PHP 5 et mySQL peut suffire. Si t'y connais rien, prends ça, c'est pas cher (- de 30 €/an avec le nom de domaine).
     

    @yann : PoC ça veut dire "démo" ?

    Proof of Concept.
  • FKDEVFKDEV Membre
    septembre 2013 modifié #13


    @FKDEV


    Je n'ai pas trop d'exemple mais dans ma courte expérience en entreprise, on se connectait aux bdd (Oracle) sans passer par des requêtes HTTP, on avait des commandes en ligne ou on utilisait un logiciel (Toad).


     


    --> Ainsi, j'imaginais que depuis mon app j'aurais pu utiliser un framework me permettant de faire une requête directement sur ma bdd.


     




     


    Sur un réseau local ou un réseau wan d'entreprise (je suppose que c'était le cas avec oracle), on le fait tout le temps de se connecter directement à  une base de donnée. Par exemple mysql sur le port 3306.


     


    Via internet, bien qu'en théorie, on pourrait le faire, on évite. Je ne connais pas toutes les raisons mais il y a des problèmes de sécurité (cf Céroce), des problèmes liés au port custom qui risque de ne pas passer les proxys.


  • Sinon avec un serveur privé on peut accéder directement à  la base de données en passant pas un VPN.


    Si c'est pour un usage "privé" c'est adapté, si c'est pour du grand public il vaut mieux passer par du HTTP.


  • Imaginons que je doive distribuer à  mon appli plein de .jpg.


    Est-ce que mySQL est une solution convenable ?


     


    Y a-t-il moyen d'interroger une base CoreData hébergée par un serveur ?


  • À ma connaissance, une "base CoreData" ça n'existe pas.


     


    Il y a des bases de données qui permettent de stocker des données structurées : mySQL, Oracle, SQL-Server, ...


     


    Il y des fichiers de données, parfois très structurés comme SQLite, au point qu'on pourrait les considérer comme une base de données. On ne trouve pas dans les fichiers de données la même richesse de service que dans les bases de données : gestion des utilisateurs, accès concurrents, intégrité des données, procédures stockées, ...


     


    Et puis il y a Core Data qui est un framework permettant de manipuler des données structurées dans une application. Les données manipulées par Core Data peuvent être stockées dans un "Store". Le store est souvent un fichier SQLite mais il peut être tout aussi bien une base de données.


  • CéroceCéroce Membre, Modérateur

    Tu peux aussi t'intéresser à  des solutions comme Parse.


    Par rapport à  ce que tu demandes, ça peut très bien convenir.



  • Il y a des bases de données qui permettent de stocker des données structurées : mySQL, Oracle, SQL-Server, ...

     

    Il y des fichiers de données, parfois très structurés comme SQLite, au point qu'on pourrait les considérer comme une base de données. On ne trouve pas dans les fichiers de données la même richesse de service que dans les bases de données : gestion des utilisateurs, accès concurrents, intégrité des données, procédures stockées, ...

     .




    On est sur du vocabulaire mais on peut considerer que SQLite est bien un systeme de base de donnees.

    C'est juste un systeme sans serveur. Comme MSAccess.

    SQLite supporte les acces concurrents mais il lui manque les autres fonctionnalités des SGBD avec serveur que tu as cités.

    La plupart des sites web qui utilisent mysql pourraient utiliser SQLite. Dans un sens, ce serait meme plus logique, puisqu'il y a deja un serveur web pour gerer les connexions et les utilisateurs.



    Un fichier de donnée pour moi, ce serait plutot du XML ou du binaire proprietaire.
  • FKDEVFKDEV Membre
    septembre 2013 modifié #19


    Y a-t-il moyen d'interroger une base CoreData hébergée par un serveur ?




     


    En solution commerciale, je pense qu'il n'y a que http://objective-cloud.com.


     


    Si tu es un aventurier, tu peux également le faire en utilisant le framework cité dans ma signature.


    Tu peux tester en local sur ton mac (avec le serveur apache pré-installé) en suivant les indications sur github. 




  • Le store est souvent un fichier SQLite mais il peut être tout aussi bien une base de données.




     


    Wow !!!


    Je ne savais pas !


    ça doit être sacrément joli (et compliqué à  mettre en oe“uvre...).


    Est-ce implémenté par Apple ou est-ce quelque chose à  mettre en place soi-même (qui génère le code pour créer les tables de la bdd ?)

  • C'est vrai que dans SQLite il y a deux parties :


    - le fichier lui-même


    - la bibliothèque qui permet d'accéder au fichier comme si c'était une base de données.


    La différence avec une vrai base de données est que la bibliothèque SQLite n'est pas liée au fichier, elle est liée à  l'application qui accède au fichier. Dans une "vraie" base de données la couche d'accès est liée au SGBD, pas à  l'application. Il y a éventuellement aussi une bibliothèque dans l'application mais on peut concevoir que cette dernière est "presque" indépendante du SGBD qui est branché derrière.


    Je maintiens mon point de vue, SQLite n'est pas une base de données.


     


    D'autre part, c'est un peu abusif de dire que SQLite gère les accès concurrents. Je ne suis pas spécialiste du domaine mais il me semble bien que le seuil verrouillage possible en SQLite3 est sur le fichier complet. C'est exactement le même fonctionnement que n'importe quel fichier : lectures simultanées autorisées, un seul process en écriture à  un moment donné.


     


    Prenons l'exemple d'un "vrai" fichier de données comme XML, que tu cites, on utilise aussi une bibliothèque dédiée dans l'application pour gérer un fichier XML. Le principe d'accès est exactement le même qu'avec SQLite.




  • Tu peux aussi t'intéresser à  des solutions comme Parse.


    Par rapport à  ce que tu demandes, ça peut très bien convenir.




     


    N'est-ce pas un peu dangereux de partir sur des solutions commerciale ?


    Genre : au début c'est gratuit/pas cher. Donc, tu le prends et tu lies ton design/ton code à  cette solution.


     


    Plus tard, ça devient trop cher... mais tu te retrouves pieds et poings liés...


     


    Sais-tu si cette solution (0€/mois) comprend l'hébergement ?


    J'imagine que oui.


    Peut-on dire alors que c'est très intéressant ?


    (il n'est pas fait mention de limite sur la taille de la "bdd" coredata)



  • Imaginons que je doive distribuer à  mon appli plein de .jpg.


    Est-ce que mySQL est une solution convenable ?


     




    Il faudrait nous en dire un peu plus sur ces jpg.


    es-tu certain d'avoir besoin d'une base de donnée pour distribuer tes jpg ?



  • C'est vrai que dans SQLite il y a deux parties :


    - le fichier lui-même


    - la bibliothèque qui permet d'accéder au fichier comme si c'était une base de données.


    La différence avec une vrai base de données est que la bibliothèque SQLite n'est pas liée au fichier, elle est liée à  l'application qui accède au fichier. Dans une "vraie" base de données la couche d'accès est liée au SGBD, pas à  l'application. Il y a éventuellement aussi une bibliothèque dans l'application mais on peut concevoir que cette dernière est "presque" indépendante du SGBD qui est branché derrière.


    Je maintiens mon point de vue, SQLite n'est pas une base de données.




     


    Sans vouloir être méchant, tu dis de la merde là ... SQLite est bien un SGBD, soit un système permettant de stocker des applications en base.


     


    Le fait que la gestion des fichiers de base soit fait par l'application elle même ou l'instance partagée lorsqu'un accès multi-process est nécessaire ne change strictement rien à  la définition d'un SGBD...


     


    Le découplage que tu as sur ce que tu appelle de "vrai" SGBD n'est là  que pour simplifier l'accès multi-user et multi-process. Chose totalement inutile pour une base mono app.



  • Si tu es un aventurier, tu peux également le faire en utilisant le framework cité dans ma signature.


    Tu peux tester en local sur ton mac (avec le serveur apache pré-installé) en suivant les indications sur github. 




     


    Je vais peut-être attendre un peu avant de configurer une server Apple... :)


     


    Sûrement plus simple dans un premier temps de faire avec SQL (que je connais) !



  • Wow !!!


    Je ne savais pas !


    ça doit être sacrément joli (et compliqué à  mettre en oe“uvre...).


    Est-ce implémenté par Apple ou est-ce quelque chose à  mettre en place soi-même (qui génère le code pour créer les tables de la bdd ?)




     


    Oui pour l'instant c'est un peu compliqué à  mettre en oeuvre.


    Apple a franchi un premier pas avec le NSIncrementalStore qui est une première brique. Mais il n'y a pas encore de connecteurs banalisés genre ODBC.



  • Il faudrait nous en dire un peu plus sur ces jpg.


    es-tu certain d'avoir besoin d'une base de donnée pour distribuer tes jpg ?




     


    à‰ventuellement, je peux stocker juste les chemins des jpg dans la base de données.


     


    Question hors sujet : quelle est la taille limite max acceptable pour une iApp iPad ?


    (je pourrai peut-être mettre mes .jpg dedans)


     


    Mes .jpg composent des "fiches utilisateur".

  • colas_colas_ Membre
    septembre 2013 modifié #28


    Oui pour l'instant c'est un peu compliqué à  mettre en oeuvre.


    Apple a franchi un premier pas avec le NSIncrementalStore qui est une première brique. Mais il n'y a pas encore de connecteurs banalisés genre ODBC.




     


    Apple ne voudrait pas embaucher quelques membres de cocoaCafé pour que ce soit finalisé vite ?


    :-*




  • Le fait que la gestion des fichiers de base soit fait par l'application elle même ou l'instance partagée lorsqu'un accès multi-process est nécessaire ne change strictement rien à  la définition d'un SGBD...




     


    Et quelle est la définition d'un SGBD ?

  • Y'a tellement de choses qui existent et y'a tellement de chose qui sont possibles !!


     


    C'est à  la fois hyper enthousiasmant et aussi un peu décourageant (car ça ne s'arrête jamais et ça paraà®t beaucoup) !!




  • Y'a tellement de choses qui existent et y'a tellement de chose qui sont possibles !!


     


    C'est à  la fois hyper enthousiasmant et aussi un peu décourageant (car ça ne s'arrête jamais et ça paraà®t beaucoup) !!




    Si tu connais SQL, te prends pas la tête. Prends un hébergement mutualisé à  3€ chez OVH en php+mysql.


    Là  tu pourras configurer ta base de donnée via phpmyadmin.


    Tu trouveras des centaines de tutos sur le sujet.


     


    Le seul inconvénient c'est que tu devras faire du php pour recevoir tes requêtes HTTP et les transformer en requête SQL vers ta base de donnée mysql. Mais là  encore, tu trouveras des tonnes de tutos.


     


    A ma connaissance, il n'y a aucune solution où tu pourrais balancer du SQL directement à  partir d'une app vers un serveur externe.

Connectez-vous ou Inscrivez-vous pour répondre.