Discussion :

[Marinetpaul]

Bonsoir à tous!

Tout d'abord merci pour l'aide apportée sur ce forum. Les réponses nous ont été d'une aide très précieuse et vendredi c'est le jour J.

Nous devons présenter à l'oral notre application de recettes de cuisine.
Le concept : l'utilisateur entre ses préférences (pas de login, pas de connexion requise) puis à partir d'un ingrédient et de quelques critères choisis (temps, budget ...) l'application lui retourne une liste de recettes.


Je pressens déjà la question suivante : "Pourquoi avez-vous choisi de stocker vis données sur SQLite et non via un serveur web ?"


1) La taille de notre BDD reste adaptée pour SQLite (mais au fait c'est quoi le maximum supporté ? et combien pèse environ une recette ?)

2) Le serveur web permet des mises à jour de l'application.
Mais avec SQLite l'utilisateur peut télécharger une nouvelle version de l'application tout en conservant ses préférences.

3) L'utilisateur ne peut pas modifier/ajouter des recettes MAIS de toute façon notre moteur de recherche par ingrédient n'aurait pas permis la casse et il aurait fallu vérifier l'orthographe de toutes les recettes entrées par l'utilisateur.

4) L'utilisateur ne peux pas poster de commentaires, bref communiquer sur les recettes. Certes

5) Point fort : il peut accéder à la base n'importe où et sans forfait 3G.
La recherche est également plus rapide. (Savez vous en gros de combien ?)

5) Point fort 2 : Pas de surcharge sur le serveur car ... pas de serveur !

Voyez vous d'autres avantages ou inconvénients ?
Ceux que je viens de citer sont-ils corrects ?

Merci d'avance pour votre aide

[Hizin]

1) La taille de notre BDD reste adaptée pour SQLite (mais au fait c'est quoi le maximum supporté ? et combien pèse environ une recette ?)

Éviter de dire ça si tu ne sais pas. Si c'est à l'état de concept avec quelques recettes tests, ou juste la réflexion. Si le point est soulevé, expliquer que ça dépend du schéma, ainsi que la quantité de données.

Pour ton point 2, pense à la question : "Oui, comme Google Play le permet naturellement. Quelle sont les différences entre votre système de mise à jour interne et la mise à jour naturelle via Play ?"

) L'utilisateur ne peut pas modifier/ajouter des recettes MAIS de toute façon notre moteur de recherche par ingrédient n'aurait pas permis la casse et il aurait fallu vérifier l'orthographe de toutes les recettes entrées par l'utilisateur.

Ben justement ... avec une BDD, tu peux faire des recherches approximatives (et la casse est le cas le plus facilement traité, avec le peu de travail que j'ai effectué dessus). Pour la modification, rien n'empêche de "dupliquer" l'originale en local et de changer ensuite selon l'utilisateur?

Souligne bien le "pas besoin de connexion internet". L'application se suffit à elle-même, et bien que la mobilité et le côté nomade à le vent en poupe, les utilisateurs aiment aussi pouvoir se passer d'une connectivité internet.

Pour ton "4" : plus rapide car tu supprimes des étapes. Pas de demande de connexion réseau, pas d'interrogation sur serveur, pas d'attente de réponse, pas de téléchargement de réponse). Juste les traits obligatoire : traitement de la demande, traitement du résultat.
Pas besoin de donner d'échelle, ou de chiffre comparatif. Montrer que des opérations ne sont pas effectuées dans la chaîne suffit pour prouver le côté "plus rapide".

[Marinetpaul]

C'est exactement la réponse que j'attendais!!

Je vais mener mes dernières enquêtes pour ne pas dire trop de bêtises infondées mais je me sens déjà plus confiante dans le choix du stockage.

Merci beaucoup

PS : Si d'autres personnes sont force de proposition pour cette question, n'hésitez surtout pas

[MrDuChnok]

Bonjour,

Concernant les limitations de SQLite en volumétrie, tu trouveras toute une page sur leur site (dans la FAQ ou un truc comme ça).
De mémoire, les limites sont suffisamment grandes pour largement contenir plusieurs millions de recettes, donc normalement je ne vois pas pourquoi ce choix pourrait être remis en cause (surtout au vue des avantages que tu tires : rapidité, souplesse, évolutivité, hors ligne, etc).

[grunk]

1) La taille de notre BDD reste adaptée pour SQLite (mais au fait c'est quoi le maximum supporté ? et combien pèse environ une recette ?)

Sqlite peut techniquement supporter des bases de plusieurs tera (14 pour être précis). Faut évidemment une machine adaptée
voir : http://www.sqlite.org/limits.html

2) Le serveur web permet des mises à jour de l'application.
Mais avec SQLite l'utilisateur peut télécharger une nouvelle version de l'application tout en conservant ses préférences.

Là j'aurais tendance à donner l'avantage au serveur web , puisque aucune manipulation n'est nécessaire pour le client. De plus une base commune à tous permet plus d’interaction dans la communauté
Utiliser une base sqlite , est un choix.

3) L'utilisateur ne peut pas modifier/ajouter des recettes MAIS de toute façon notre moteur de recherche par ingrédient n'aurait pas permis la casse et il aurait fallu vérifier l'orthographe de toutes les recettes entrées par l'utilisateur.

Comme déjà expliqué une base de données permet des recherche approximative , donc mauvais argument. Vous pouvez toujours dire que ca sera pour une prochaine version.

4) L'utilisateur ne peux pas poster de commentaires, bref communiquer sur les recettes. Certes

Pas un problème pour moi. Ca évite de devoir mettr en place une équipe de modération.

5) Point fort : il peut accéder à la base n'importe où et sans forfait 3G.
La recherche est également plus rapide. (Savez vous en gros de combien ?)

C'est l'argument massue pour le choix de sqlite et non d'un serveur web. D'un autre coté pour interroger un web service du edge suffit , et les utilisateur de ce genre d'appli ont tous un forfait data ou du wifi.
La recherche sur un grosse base sera pour moi plus rapide sur un serveur dédié à cette tache , même si tu rajoute les 40 ou 50ms de latence du réseau. Après dans des conditions dégradées effectivement la base locale est plus performante.

5) Point fort 2 : Pas de surcharge sur le serveur car ... pas de serveur !

Faux problème. Tu me dis ça pendant une soutenance je te répond : "Pas de bonne note car... pas de bonne réponse"

[Marinetpaul]

Merci beaucoup pour cette réponse, j'éviterai ainsi de grosses gaffes pour ma soutenance orale demain matin à 8h

J'ai encore quelques points douteux, il me semble qu'avec mon choix les mises à jour sont possibles via google play. Mais je ne comprends pas vraiment le fonctionnement.

De même je pense qu'il est possible qu'il modifie les recettes ou en ajoute (on créerait un système anti-casse, car comme tu l'as dit c'est possible, au cas où il ferait des fautes d'orthographe) et ses recettes perso seraient stockées sur son android directement dans un nouveau fichier. Seulement elles ne seraient pas visibles pour les autres utilisateurs.

Qu'en pensez-vous ?


Pour les fonctions de sqlite que nous allons utiliser c'est un peu confus.
Ce qui est sur c'est que nous aurons besoin du "sharedpreference".
Mais pour la création des recettes perso je n'ai pas trouvé de code/fonction.

Pour finir, le dernier soucis est l'import de photo. Il parait que sqlite ne prévoit pas le format bitmap. Comment faire ?

Enfin si vous voyez d'autres avantages de sqlite n'hésitez pas.


Mille merci pour cette aide de dernière minute

[Hizin]

J'ai encore quelques points douteux, il me semble qu'avec mon choix les mises à jour sont possibles via google play. Mais je ne comprends pas vraiment le fonctionnement.

De base, les mises à jours se font (et sont automatiquement gérées) par Play. Ton système permet un contrôle plus fin, en permettant de ne mettre à jour que les données de manière indépendante à Play.

Prend le cas : ajout d'une recette.
Avec la mise à jour via Play, il faut refaire le cycle de publication avec la nouvelle info, et que l'utilisateur fasse la mise à jour.
Avec ton système de web-service, il suffit de mettre à jour les données demandées par l'application, et c'est transparent (trop dans certains cas) pour les utilisateurs.

Pour les fonctions de sqlite que nous allons utiliser c'est un peu confus.
Ce qui est sur c'est que nous aurons besoin du "sharedpreference".
Mais pour la création des recettes perso je n'ai pas trouvé de code/fonction.

Tu mélanges de nouveau ^^

Le mécanisme des SharedPreferences permet de sauvegarder des informations, tout comme SQLite. Les deux n'ont rien à voir. Les SharedPreferences sont plus adapté aux "petites" informations (des préférences, justement).

Pour les recettes, ce sera à vous de vous y coller. En informatique, pas de bouton magique "j'ai une idée, crée-moi tout ce qu'il faut pour la réaliser".

Pour finir, le dernier soucis est l'import de photo. Il parait que sqlite ne prévoit pas le format bitmap. Comment faire ?

Tu ne t'es pas vraiment renseigné sur les BDD, non ?
Type BLOB.

Conseils : lire des livres/cours/ressources/tutoriels utiles sur Android et sur les bases de données orientés débutant.

[grunk]

Pour finir, le dernier soucis est l'import de photo. Il parait que sqlite ne prévoit pas le format bitmap. Comment faire ?

C'est possible mais en général on évite de stocker les photos directement dans la base.
On préférera un champs texte avec le chemin ou le nom de l'image sur le stockage du téléphone. Ça permet de de garder une base légère.

[sinok]

A noter que l'update de données en publiant via google play, ça risque d'être lourd pour vous.

Une solution intermédiaire serait de stocker un fichier de recettes statique (genre du XML/json+des images dans un zip, avec une empreinte MD5 dans un autre fichier pour s'assurer de l'intégrité après download) sur un serveur web quelque part que ton application ira vérifier de temps à autre, quand une connexion est disponible. Une fois l'appli récupérée, elle mettra à jour la base et les images en fonction de ce qu'elle vient de recevoir.

Cela vous fournira bien plus de souplesse pour ajouter des recettes, sans avoir besoin d'une base de données sur le web, ce sera un simple téléchargement de fichier, pas besoin de google play...