Bonjour à tous,

J'ai un peu cherché, mais ne sachant pas trop quoi chercher, ni où, je viens poster ici.

Voici mon problème, je suis en train de développer une application mobile avec React Native qui nécessite une base de donnée. C'est la première fois que j'ai un projet qui nécessite une DB, et je suis complètement novice dans ce domaine.

J'ai pensé me pencher sur FireBase qui avait l'air assez intéressant dans mon cas, et pas mal conseillé sur les forums pour les débutants dans ce domaine. Mais j'ai vu sur certains forums que c'est bien pour commencer, mais que son usage devient handicapant quand on parle de grosses base de données, est-ce vrai ? Dans quelles mesures et quelles limites ? 

D'autre part, j'ai dans mon application un système de sondage, et j'aimerai que chaque user puisse voter qu'une seule fois par sondage, c'est alors que ma question se pose au niveau de l'architecture de la DB.

Pour chaque users stocker tous les sondages au quel il a déjà répondu, pour pouvoir l'empêcher de revoter?

Ou alors partir sur autre chose, stocké localement dans le téléphone (LocalStorage) ? Ou encore autre chose ?

Je suis ouvert à toutes propositions, j'ai peu d'expériences et je cherche à en acquérir à travers ce projet, c'est pourquoi je viens poster ici.

EDIT : J'ai oublié de préciser, mais le nombre de sondage aux quels chaque users pourra répondre sera relativement grand (plusieurs milliers)

Merci !

-
Edité par robyy-22 8 octobre 2018 à 15:10:53

Bonjour,

Tu parles d'une application mobile, donc je suppose que la base de données sera distante (sur un serveur) et accessible depuis Internet.

Dans ce contexte tu vas de voir prendre un serveur pour héberger ta base de données.

Si tu veux un serveur gratuit, ou peu cher, ce sera un serveur mutualisé, ce qui risque de t'imposer MySQL comme système de gestion de ta base de données ...

Ensuite, il va falloir développer une API (type REST) sur le serveur pour qu'il communique facilement vers l'extérieur. Les différentes utilisateurs via l'application mobile enverront des requêtes à l'API qui les traitera, communiquera avec la BDD, et retournera une réponse.

Concernant la BDD, tu peux voir simple :

• utilisateur ( id [pk], email, password, etc. )
• sondage ( id [pk], titre, date_creation, date_fin, etc. )
• choix ( id [pk], id_sondage [fk], intitule, etc. )
• reponse ( id_utilisateur [pk][fk], id_sondage [pk][fk], id_choix [fk] )

La dernière table permet de déterminer à quels sondages un utilisateur a participé (ou n'a pas participé) et empêche, par la clé primaire composite, de stocker deux fois le même couple utilisateur/sondage ...

Merci pour toutes ces réponses, mais j'avais crû comprendre que justement FireBase évitait tout ça ? L'hébergement sur un serveur mutualisé etc ? Je me trompe ? 

Et merci, je suis plus éclairé sur l'architecture de la BDD

Firebase est une plateforme d'hébergement de bases de données NoSQL maintenue par Google. Ce service propose en effet de simplifier toute la gestion des données, notamment dans le cadre d'une application mobile.

Deux choses.

C'est du NoSQL, donc pas de données relationnelles comme proposé précédemment. Bon, cela ne semble pas trop gênant dans ton cas.

C'est Google ... donc dépendance à leur politique de services ...

Personnellement je n'ai jamais utilisé Firebase donc je n'aurais pas d'avis sur le sujet ni ne pourrait t'apporter d'aide

D'accord ok, je vais continuer mes recherches et voir ce qui correspond le mieux à ce que je recherche, merci de l'aide en tout cas !

Si jamais un utilisateur confirmé de firebase passe par là..

Merci Benzouye pour tes réponses claire ! En quoi consiste une API ? J'ai encore du mal à comprendre ..

Je vais continuer les recherches de mon coté.

API : Application Programming Interface (Interface de Programmation Applicative).

C'est une structure de programmation permettant l'échange entre deux applications.

Dans les faits cela consiste à mettre à disposition des développeurs des méthodes de dialogue documentées (en général) permettant de communiquer de manière maîtrisée avec l'application qui met à disposition l'API.

Exemple : Google met à disposition des développeurs une API Google Maps. Google fourni donc un ensemble de méthodes documentées permettant à un développeur d'interroger les données cartographique qu'ils possèdent et de les exploiter dans sa propre application.

Actuellement, on parle beaucoup d'API REST, c'est plus ou moins un standard dans le développement applicatif web. OC propose un cours là-dessus : https://openclassrooms.com/fr/courses/3449001-utilisez-des-api-rest-dans-vos-projets-web

-
Edité par Benzouye 9 octobre 2018 à 13:03:53

Merci Benzouye !

Donc en fait si je comprend bien, il s'agit en fait d'une forme de "prêt à fabriquer" pour l'interopérabilité entre applications, c'est bien ça ?

"prêt à fabriquer" n'évoque rien pour moi ... du coup joker

En revanche, oui pour "interopérabilité". Une API est sensée faciliter l'interopérabilité entre applications.

Il faut aussi bien voir que chaque application peut proposer son API.

Exemple :

Soit une application d'agenda qui propose une API de consultation de l'agenda selon le type de rendez-vous

Soit une application de cinéma qui propose une API de consultation des films et séances

On peut alors imaginer que l'app d'agenda utilise l'API de l'app cinéma pour créer un rendez-vous de type "séance de film"

On peut imaginer que l'app de cinéma utilise l'API de l'app agenda pour compter tous les rendez-vous de type "séance de film"

Si l'app agenda vient à évoluer (refonte partielle ou totale du code), normalement le développeur va assurer la continuité de l'API, ainsi les app l'utilisant ne seront pas perdues, même si toute la partie code à changer derrière ...

-
Edité par Benzouye 10 octobre 2018 à 14:37:31