Discussion :

[Karly]

Salut à tous, je développe une application qui va permettre d'une part de stocker des infos personnels dans une base de données interne SQLITE et d'une autre de les partager avec des amis qui ont aussi l'application et qui pourront commenter et coter ce qui est partagé. Le truc c'est que je sais pas trop comment mettre ca en place et quel SGBD serait l'idéal (mysql, sql server 2008 ??)? Y en a t il un qui est idéal à utiliser avec android ?

Pour le moment j'ai presque fini mon application en interne et je m'aprette à me lancer dans le partie serveur mais la je ne sais pas par ou commencer ni quelle est la meilleure maniere de m'y prendre :S j'ai vu qu'il y avait des tutos mais je sais jamais trop si c'est adapté ou pas a l'application que je veux faire :s

Quelqu'un a un tuyaux ?

[kracels]

Salut, a mon avis tu devrais developper un web service avec une architecture dans ce genre la :

mobile -- serveur web -- base de données

et il faudrait que tu synchronise que les données de ta BDD qui ne son pas encore sur ton serveur sinon ca risque de saturée ton app si tu synchrnoise a chaque fois toutes les données :p ...Mtn je sais pas plus t aider que ca car mes connaissances sont assez limité sur ce sujet :S sorry

[Willy55]

Bonjour,

Bon, alors même si ton explication de projet n'est pas complète, je vais tenter de te donner quelques indications

Comme SGBD coté serveur je dirait sans hésiter MySQL !
Pourquoi ? Si tu es débutant c'est le plus simple non seulement pour te faire une interface Web PHP à coté pour le serveur mais également pour la communication avec la ton application android, c'est des appels de scripts en PHP stockés sur le serveur. La communication se fait en JSON c'est vraiment pas compliqué.

Si ton application est a titre personnel et que le volume de données n'est pas trop important cette idée est la plus simple. Des scripts PHP sur le serveur qui exécutent les requêtes dans la base MySQL et l'application appelle ces scripts.

Si l'appli est plus orienté professionnel et/ou que le volume de données et conséquent il faudra peut-être t'orienter vers un serveur d'application.

A toi de voir

[Karly]

Merci pour vos réponses !

Bonjour,

Bon, alors même si ton explication de projet n'est pas complète, je vais tenter de te donner quelques indications

Comme SGBD coté serveur je dirait sans hésiter MySQL !
Pourquoi ? Si tu es débutant c'est le plus simple non seulement pour te faire une interface Web PHP à coté pour le serveur mais également pour la communication avec la ton application android, c'est des appels de scripts en PHP stockés sur le serveur. La communication se fait en JSON c'est vraiment pas compliqué.

Si ton application est a titre personnel et que le volume de données n'est pas trop important cette idée est la plus simple. Des scripts PHP sur le serveur qui exécutent les requêtes dans la base MySQL et l'application appelle ces scripts.

Si l'appli est plus orienté professionnel et/ou que le volume de données et conséquent il faudra peut-être t'orienter vers un serveur d'application.

A toi de voir

En fait il s'agit de mon travail de fin études et c'est pour ca que je sais aps si du MySQL fera l affaire :s surement que oui dans le sens ou pas grand monde risque d'utiliser mon application mais je pense que mes profs s'attendent a du solide :S ... En fait on pour résumé l'application d'une part elle permet de partagé un "rappel" donc si tu veux rappelé a un pote qu'il doit faire quelque chose ou si une mère veut que son fils n'oubli pas d'aller chez le dentiste ben elle lui envoi ce rappel avec titre, texte, localisation si nécessaire (donc dans la bdd l'adresse ou bien lat, long) s'il doit se rendre quelque part et une alarme si nécessaire aussi (un string indiquant l'heure dans la bdd). Ca c'est la premiere info qu'il est possible de partager. Ensuite il y a aussi moyen de partager des informations comme par exemple le nom d'un restaurant avec sa localisation un texte descriptif et la possibilité aux gens avec qui on partage cette info de mettre une cote s'ils connaissent le resto et laisser un avis dessus (je compte limiter les commentaires/avis à max 10 pour que ca ne devienne pas non plus un forum de discussion :p)

Voila pour te donner une idée de l'application :p par contre a ma défense orale un des profs m avait suggéré comme toi de peut etre faire un serveur d'application mais la j'ai aucune idée de comment ca marche et si c est vrmt nécessaire :s

[Willy55]

D'accord je vois l'idée

Si ça peut te donner une indication, pour mon projet tuteuré en DUT informatique il y a 1 mois, notre projet était un site web pour les restaurateurs et deux applications (android & iphone) pour commander à l'avance dans les restaurants. Les commandes étaient reçu en temps réel sur le compte du restaurateur connecté sur le site web.

C'est moi qui était chargé de l'application android et je n'ai pas fait de serveur d'application, j'ai fait une connexion directe à la base, c'est moins bien et moins sécurisé j'ai eu l'occasion de l'apprendre juste après pour mon stage mais c'est aussi beaucoup plus simple si tu débute.

Voila mais c'est toi qui vois, si tu choisis le serveur d'application tu peux t'orienter sur symfony.

[Hizin]

Le mécanisme des notifications semblent couvrir une bonne partie de ce que tu veux dans un premier temps.

[Karly]

Ok merci pour les tuyaux Willy55 ;-)

Le mécanisme des notifications semblent couvrir une bonne partie de ce que tu veux dans un premier temps.

Je ne comprends pas bien ce que tu veux dire par la :s

[nicroman]

Je pense qu'il y a plein d'infos sur les Serveurs + SGBD sur developpez et tu trouveras certainement les informations nécessaires...

Ensuite, il faut estimer le nombre de 'hits' sur ton serveur, et le type de hits: mise à jour, simple "get", etc...

MySQL est une bonne base de données pour de petits projets, suffisamment de ressources dessus (forcément c'est gratuit),...

Par contre, dès qu'on veut s'amuser avec de la réplication (un ou deux serveurs BD qui font les "select", un serveur BD d'update, un serveur "maitre" par exemple) afin d'accélerer les requetes, il faut passer à un vrai SGBD comme Oracle.

Pour info, nous recevons sur nos serveurs 2 hits par minute (1 hit sur 5 comporte des nouvelles données), et nous avons 3 serveurs d'application (Tomcat) sur 1 base de donnée (Oracle), et ça tourne bien.

[Hizin]

En fait on pour résumé l'application d'une part elle permet de partagé un "rappel" donc si tu veux rappelé a un pote qu'il doit faire quelque chose ou si une mère veut que son fils n'oubli pas d'aller chez le dentiste ben elle lui envoi ce rappel avec titre, texte, localisation si nécessaire (donc dans la bdd l'adresse ou bien lat, long) s'il doit se rendre quelque part et une alarme si nécessaire aussi (un string indiquant l'heure dans la bdd).

Une notification te permet le contrôle du vibreur, est gratuite, te permet d'envoyer du texte (différenciant titre et message), ainsi que des extras et est natif à Android.
Avec ce mécanisme, et la prise en main de celle-ci du côté appli, tu prends donc en compte tout ce côté là. Le service C2DM de Google est fait pour ça.

Pour le côté "partage" par contre, ce n'est pas adapté.

[fr1man]

Pour info, nous recevons sur nos serveurs 2 hits par minute (1 hit sur 5 comporte des nouvelles données), et nous avons 3 serveurs d'application (Tomcat) sur 1 base de donnée (Oracle), et ça tourne bien.

Par minute ou seconde ?
Parce qu'avant de saturer MySQL, faut y aller quand meme !

[nicroman]

Oups.. typo... par seconde

MySQL est excellent juste pas très adapté à de multiples instances de serveurs... Tant qu'on reste sur un serveur avec pas trop de rows par table ca va... Meme si MySQL Cluster améliore les choses...

Ensuite, MySQL peut avoir des problêmes avec les requetes velues (je ne suis pas sur que MySQL supporte les materialized views par exemple).

[Karly]

Voila a quoi ressemble une ébauche de ma base de données



Donc rarement beaucoup de colonne et à peine 10 tables, est ce qu'une telle base de données nécessite plus que du Mysql ? Et si oui, en imaginant que y ait plein de connexion dessus est ce que ca tiendrait le coup ?

Y aura jms plein de connexions dessus je sais mais pour mes profs il faut que j'arrive a justifier mes choix de sgbd serveur pourquoi est ce que j'aurais choisi mysql et pas mis en place un serveur d'application (que je ne vois pas du tout comment ca marche ni sa fonction exacte). Enfin voila donc si du Mysql fait l'affaire ben je penche pour :p c est sur ...

[fr1man]

Il faut voir les fonctionnalités des sgbd dont tu auras besoin.
Si tu n'as pas besoin de choses complexes, pars sur mysql et justifie le fait que si le besoin s'en fait ressentir plus tard, tu pourras changer de sgbd pour oracle ou autre.
Niveau performances, tu peux voir venir avant de saturer mysql.

[kracels]

A premiere vue, vu le peu de tables et de colonnes dessus je pense que du mysql ferait l'affaire maintenant s'il y a vraiment beaucoup de connexions c'est vrai que ca pourrait saturer mais comme l'a indiqué fr1man avant que Mysql ne sature il faut deja y aller ...

[Karly]

Je viens déterrer ce sujet désolé :p au niveau du choix du sgbd : est ce que mysql convient toujours si j'utilise des images : une (facultative) par objet INFORMATION_REMINDER, une (facultative) par objet TASKREMINDER, et une (facultative) pour la photo de profil du user ?

[Simon MARQUIS]

Ca dépend. Si par "image" tu entends url d'une image, là il n'y a pas de problème, tu peux continuer à utiliser MySQL. Dans l'autre cas, je ne sais pas...

[kracels]

Karly je crois que tu confond serveur de BDD et serveur de fichier ... tes images elles sont pas dans ta base de données même elles sont stocké dans un serveur de fichier. Ce que tu peut faire c'est mettre l'url de l'image vers son emplacement dans le serveur de fichier ;-)

Ou alors je me trompe completement mais moi je vois la chose comme ca ... Tu as d'une part ton serveur de BDD ou il y a ta BDD, ton serveur web ou tu vas mettre tes scripts php ou autres et enfin un serveur de fichier si tu veux pouvoir accéder a des fichiers comme des images ...

[Karly]

Ok ! Merci pour vos éclaircissements ;-)