@Godrik : le problème est simplement de savoir si une recherche "plein texte" est plus effective sur une BDD ou sur des objets (au sens POO) chargés en mémoire vive, grosso-modo ^^'

@_skip : Merci pour la réponse détaillée. Je ne pensais pas avoir autant d'infos
C'est la première fois que nous sommes tout les deux amenés à faire une recherche, et on se rend compte "à la dure" que c'est beaucoup moins trivial que ça en à l'air. Niveau dév' pur, on se débrouille sans trop de problème, mais quand on commence a aborder cette problématique de recherche ... on commence à sécher pour le coup, le sujet étant complexe et celui-ci disposant d'énormément de ressources.

C'est bien une application d'informations. Chaque IHM est construite grâce aux données, et c'est ce point-là qui me fait penser que les décentraliser sera difficile. Les IHM ressentiront un décalage plus ou moins important, et ça entraînera une consommation (pas énorme vu les données, mais qui peut l'être à la longue) du forfait 3G de l'utilisateur, ou ça requerra une connexion Wifi permanente, ce qui est embêtant aussi pour l'utilisateur, celui-ci ne disposant pas forcément d'un point Wifi auquel se connecter.
La recherche est une "petite" fonctionnalité (naviguer dans les formations d'une université, on peut vite se perdre).

Merci des détails apporté. On y voit un peu plus clair. Je pense que l'on verra avec le client (si la BDD est un impératif ou non) et que l'on fera quelques tests grandeur nature (ou au moins représentatif) qui nous aideront dans notre choix définitif.

Hors-sujet : ça faisait longtemps que je n'avais pas eu l'impression d'être largué sur un sujet, ça fait du bien et ça donne envie d'en apprendre plus

Bunyan
Posté le 27 avril 2012 à 15:12:07
""@Godrik : le problème est simplement de savoir si une recherche "plein texte" est plus effective sur une BDD ou sur des objets (au sens POO) chargés en mémoire vive, grosso-modo ^^'""

Faire un travail en mémoire plutôt que sur disque sera toujours plus rapide. Le problème c'est que la mémoire c'est limité et que ce n'est pas persistant par nature.

""Maintenant les structures de données dont je t'ai parlées peuvent tout à fait être modélisées en objet. Ton problème reste le même : il te faut un index et un ranking que tu travailles sur disque ou en mémoire.""

""@_skip : Merci pour la réponse détaillée. Je ne pensais pas avoir autant d'infos
C'est la première fois que nous sommes tout les deux amenés à faire une recherche, et on se rend compte "à la dure" que c'est beaucoup moins trivial que ça en à l'air. Niveau dév' pur, on se débrouille sans trop de problème, mais quand on commence a aborder cette problématique de recherche ... on commence à sécher pour le coup, le sujet étant complexe et celui-ci disposant d'énormément de ressources.""

C'est clair, savoir programmer c'est 5% au grand max de ce qu'il faut pour créer une solution à un problème.

""C'est bien une application d'informations. Chaque IHM est construite grâce aux données, et c'est ce point-là qui me fait penser que les décentraliser sera difficile. Les IHM ressentiront un décalage plus ou moins important, et ça entraînera une consommation (pas énorme vu les données, mais qui peut l'être à la longue) du forfait 3G de l'utilisateur, ou ça requerra une connexion Wifi permanente, ce qui est embêtant aussi pour l'utilisateur, celui-ci ne disposant pas forcément d'un point Wifi auquel se connecter.
La recherche est une "petite" fonctionnalité (naviguer dans les formations d'une université, on peut vite se perdre).""

Après il faut voir si tes utilisateurs sont pendus dessus toute la journée ou s'il consulte périodiquement comme pour leur mail. C'est un tradeoff :

1) Application dans mobile :
- Mise à jour du contenu chiante
- Ressources limitées
- Moins de middlewares à disposition
- Recherche fastidieuse et limitée
+ Autonome et sans besoin de liaison wi-fi
+ Plus rapide même si ça reste à prouver suivant les I/O nécessaires, c'est un mobile quand même.

2) Application client-serveur ou web :
+ Mise à jour du contenu simple et efficace (c'est centralisé)
+ Ressources en abondance côté serveur
+ Libs à disposition pour la recherche = nettement plus puissante.
- Problème de réseaux : peut être lenteur voire indisponibilité.

Pour le reste bon courage, une BDD a du sens si elle te permet d'être plus performant ou de mieux résoudre tes problèmes de stockage et restitution des données.
Aucun client n'est assez con pour exiger que tu utilises une BDD si ça n'apporte strictement rien côté fonctionnalités. Ce choix vous appartient à vous par rapport au problème qu'on vous soumet.

En plus tu peux opter pour un mix : stocker le gros des données en BDD, et n'avoir que tes indexs en mémoire. Sur mes applications au boulot, je combine allègrement BDD, fichiers csv et index mémoire dans une même application.

Je ne susi toujours pas bien sur d'avoir compris, mais de la recherche exacte dans un texte, c'est aussi facile qu'une table de hashage. Tu parlais d'un temps de 2 minutes. Qu'est ce qui prends deux minutes ? ecrire ton fichier sur disque (enfin sur le support de stockage) ?

Une table de hashage pour un millier de mots, ca devrait pas etre bien gros.

@_skip : "Faire un travail en mémoire plutôt que sur disque sera toujours plus rapide. Le problème c'est que la mémoire c'est limité et que ce n'est pas persistant par nature. "

Ce qui me remet en mémoire une autre contrainte : la mémoire vive est limitée sur terminal mobile Android (généralement à 32 Mo, mais fluctuant et dépendant des téléphones à priori).

"Après il faut voir si tes utilisateurs sont pendus dessus toute la journée ou s'il consulte périodiquement comme pour leur mail. "

Je ne pense pas, mais la condition de disponibilité constante et de fluidité est au coeur des demandes.
Les mises à jour du contenu devraient être de l'ordre d'une fois par an je pense, lors des changements de programmes ou de postes (quoi que ... avec les postes, ça peut faire plus fréquents).

"Pour le reste bon courage,"
Merci

"En plus tu peux opter pour un mix : stocker le gros des données en BDD, et n'avoir que tes indexs en mémoire. Sur mes applications au boulot, je combine allègrement BDD, fichiers csv et index mémoire dans une même application. "

Je vais garder celle-là en mémoire aussi du coup.

Merci pour tout les détails et le temps accordé, en espérant pouvoir te rendre la pareil un jour

@Godrik : ce qui prend 2 minutes, c'est le parsing de fichiers XML et JSON + la création de la base + l'insertion en base de 15% des données parsées (uniquement le contenu des fichiers JSON).

L'appli parse des fichiers, pour en récupérer les données, puis en enregistre certaines (le développement de cette partie n'est pas encore finie par l'autre équipe) qui représente environs 15% des données totales.

Le parsing seul prend de 2 à 8 secondes selon nos tests, dépendant du téléphone.
Le parsing + la création de la base + l'insertion en base prend de 23 à ~120 secondes.

Je n'effectue encore aucune recherche à ce stade, je me demande et me renseigne

De rien, j'aime bien les discussions techniques.
Et puis ça change des "je veux apprendre le C pour faire des jeux vidéos".

Un dernier point par rapport à sqlite, il y a des techniques pour faciliter le bulk insert. Genre si tu effectues toutes tes insertions dans la même transaction en réutilisant des requêtes préparées, tu peux énormément gagner en vitesse.

"@Godrik : ce qui prend 2 minutes, c'est le parsing de fichiers XML et JSON + la création de la base + l'insertion en base de 15% des données parsées (uniquement le contenu des fichiers JSON)."

J'ai fait du parsing d'XML en C++ recement, et j'avais une difference de performance enorme en fonction de la lib utilise. Apres j'imagine que sur android il y a un composant systeme qui fait le parsing d'XML...

Tu fais bien tes I/Os de facon asynchrones?

Ah, ça, ça m'intéresse grandement.
Le terme en soit m'en apprend déjà pas mal et me donne plusieurs pistes.
Je connaissais les "prepared statements", mais je ne pensais pas que ça impactait autant.

Message croisé !

Les fichiers sont parsés les uns après les autres dans un thread dédié à ça (pour info : opération longue en thread principal causant une exception à partir de Android 3).
Vu que le parsing prend un temps acceptable selon nous pour une opération ne devant être effectuée qu'une fois, nous n'avons pas touché à cette partie de l'application.
Là, par contre, la question se repose si l'on ne met pas de base de données en place.

Pour le parsing, c'est un XMLPullParser qui est utilisé (à priori, une variante de StAX).

L'insertion de plein données pour charger une table, on s'y réfère souvent avec le terme "bulk insert". Sous sqlite en général il y a deux ou trois moyens d'accélérer sensiblement l'opération.

J'ai juste tapé "sqlite bulk insert" dans google je tombe sur ceci.
Tiens cadeau :

http://sagistech.blogspot.com/2010/07/notes-on-android-sqlite-bukl-insert.html

Mais pourquoi ne pas livrer la DDB toute prête avec l'application?

C'est prévu.
Mais vu qu'il y a aussi des mises à jour de contenu sans mise à jour d'application de prévu, cet aspect demeure important.

Et merci pour le lien aussi (je viens de le voir x) ) !

Voir: https://www.jeuxvideo.com/forums/1-47-46404-47-0-1-0-printf-blabla.htm#message_63902

Je suis entrain d'essayer d'ordonner tout ça.

Là je bloque sur un truc (niveau débutant, pas de moquerie hein? )

En fait, j'aimerais faire ceci

FonctionStats:
"Stats du perso:
Force
Vitesse
etc"

FonctionTourparTour:
"Tour = Vitesse * 2"

En gros, je veux utiliser une variable de ma fonction Stats dans ma fonction TourparTour, mais forcément, il ne la reconnait pas.

Je sais que je peux la déclarer au niveau de la classe, mais ça ne correspond pas tellement à ce que je veux faire.

Je pose la question tout en continuant à chercher. Merci

Finalement, j'ai déclaré au niveau de la classe.
Je m'embrouille l'esprit des fois

Encore moi:

public static int Injury(int prio){
if (prio == 1){
playerHealth = playerHealth - Attack (mobDmg, mobCritical);
System.out.println(mob + " vous inflige " + Attack (mobDmg, mobCritical) + " de dégâts.");
System.out.println ("Il vous reste " + playerHealth + " PV.");

[...]

Dans ce bout de code, on voit que la fonction Attack est lancée 2 fois, alors que je voudrais simplement récupérer la valeur de sa première itération.

Dois-je la stocker dans une variable obligatoirement?

Genre

public static int Injury(int prio){
int degat;
if (prio == 1){
degat = Attack (mobDmg, mobCritical)
playerHealth = playerHealth - degat;
System.out.println(mob + " vous inflige " + degat + " de dégâts.");
System.out.println ("Il vous reste " + playerHealth + " PV.");

ou y a-t-il une autre possibilité?

Merci

(Désolé avec toutes mes Question à la con)

Salut, j'ai avancé un peu dans la POO mais il y a un truc que j'ai pas bien saisi:

Disons que j'ai deux cas:

Cas N°1

Classe Main avec fonction main:

public class Main {

public static void main(String[] args) {

Blabla.afficher();

}
}

Classe Blabla:

public class Blabla {

public static void afficher ()
{
System.out.print("Test")
}
}

Cas N°2

public class Main {

public static void main(String[] args) {

Blabla texte = new Blabla ()

texte.afficher()

}
}

Classe Blabla

public class Blabla {

public void afficher() {
System.out.print("Test");
}
}

En fait, je ne sais pas bien quelle est la différence entre les deux?
Je sais que je n'utilise pas le mot static à tout va, donc je pense que je squatte moins de mémoire... Mais sinon ça change quoi?

Merci pour vos conseils

Pour le peu de souvenir qu'il me reste le static est pour éviter la création d'ojet "jetable". On peut les utiliser sans créer d'instance par exemple la classe Math...

En fait j'arrive à visualiser son utilité dans certains contextes, mais j'arrive pas à bien définir ce que c'est.

Enfin c'est dur à expliquer ce que je ne comprends pas, vu que je ne le comprends pas

Bref, je continue, à force, je finirai bien par tomber sur un problème qui m'ouvrira les yeux.

"Dans ce bout de code, on voit que la fonction Attack est lancée 2 fois, alors que je voudrais simplement récupérer la valeur de sa première itération.
Dois-je la stocker dans une variable obligatoirement?"

Yep.

" ou y a-t-il une autre possibilité"
Oui, mais c'est complique et pas forcement utile. Le principe est de rendre ta fonction sans effet de bord de facon a ce que deux appels successif obtiennent le meme resultat. Ici, cela consiste a rendre le generateur aleatoire interne a la fonction attaque et a n'avancer le stade de son generateur que lorsque le "tour" change.

(J'ai l'impression que c'est du java, donc je reponds en Java)

Quand une fonction est statique, elle n'utilise pas d'etat interne de l'objet. Ce sont souvent des fonctions utilitaire directement relier a l'objet mais qui ne fonctionne pas sur un objet directement.

Par exemple, j'utilise courement des fonctions statiques pour constuire un objet.

class Personnage
{
..//plenty of things

public static Personnage load_from_file (String filename);
}

Ici, cela permet a load_from_file de creer l'objet personnage de la facon qui l'interesse. En particulier, de retourner un objet derive de Personnage est possible a partir de cette fonction.