Discussion :

[freud]

Bonsoir à tous,

J'ouvre le même sujet que j'ai ouvert dans le forum Débats sur le développement - Le Best Of . (Type de développement) Je pense que je ne l'ai pas ouvert dans le bon forum. Mon sujet est en rapport avec de la conception.

E ce moment je suis confronté à un dilemme qui me bloque sans prendre la décision qui convient et plus le temps passe et plus ça me retarde mon travail.

Ma préoccupation est probablement liée à des méthodes de génie logiciels.

Je m'explique :


J'ai entamé un nouveau projet de gestion de stocks et de gestion commerciale qui doit fonctionner en client/serveur avec le couple FireBird/delphi.
Dans la base de données je dois gérer des articles avec de nombreuses informations. Rien que pour la table des articles, celle-ci devra contenir une cinquantaine de champs avec en plus ces tables connexes dont les stocks, les articles_fournisseurs, les emplacements, les entités renfermant ces emplacements, les compositions d'articles. Tous cela, sera organiser en onglet pour chaque table connexe et grille de données pour les codes, noms articles etc... Donc, avec ces quantités volumineuses d'informations, pour l'affichage client, faut-il organiser cela en grille de données (liste) notamment pour la table des articles sachant que leurs nombres atteindra probablement quelque centaines de milliers ce qui me semble, deviendra assez lourd pour l'affichage à l'écran de l'application cliente ou juste proposer, dans l'écran, la recherche de l'article et son affichage.
A vrai dire, dans les applications que j'ai eu à faire, je n'avais pas reflechi à cela pour la simple raison que les lignes de données escomptés ne dépasserait pas les dizaines de milliers dans un développement en local. Mais dans le C/S le contexte devient différents et je n'ai pas eu affaire à des applicatifs gérant des BDD de 300 ou 500 000 articles.

Donc faut-il opter pour des écrans à grilles de données ou des écrans ne proposant que des recherche et affichage si trouver dans un contexte C/S à données volumineuses ?

Si quelques un ont en fait l'expérience notamment avec des ERP ?

Merci pour vos réponses.

[ego]

Avant de chercher une solution technique, il faut se concentrer sur le métier lui-même et le mode de travail des gens.
Un humain ne recherche pas qq chose dans une liste de plusieurs milliers d'items. Il fait en général des recherches via des critères, ces critères étant censés ramener un nombre limité d'items.
Donc il ne faut pas trop se préoccuper de la volumétrie dans un premier temps mais surtout essayer de comprendre comment l'application sera utilisée.
Ensuite, si tu te rends compte que tu vas devoir afficher des milliers d'items, tu pourras en parler au métier et leur demander : "Mais êtes vous sûr que vos utilisateurs vont s'y retrouver dans cette jungle d'items ?"

Bref, le métier avant tout

[freud]

Bonjour et merci pour votre réponse

il ne faut pas trop se préoccuper de la volumétrie dans un premier temps.....

C'est vrai, je me suis poser la question du pourquoi de cette préoccupation sachant que cette volumétrie ne sera, probablement pas atteinte immédiatement après la mise en œuvre de l'application. J'ai comme brulé l'étape de la maintenance de l'application qui offre la possibilité de palier à ces problèmes. D'autant que dans un contexte C/S c'est la partie cliente (les écrans) qui doivent-être adaptés à la volumétrie et comme je développe tout dans la BDD...... alors je me concentrerais sur les métiers en faisant en sorte que la BDD puisse être indépendante par rapport au client.

Merci ego

[montesq]

C'est vrai, je me suis poser la question du pourquoi de cette préoccupation sachant que cette volumétrie ne sera, probablement pas atteinte immédiatement après la mise en œuvre de l'application. J'ai comme brulé l'étape de la maintenance de l'application qui offre la possibilité de palier à ces problèmes.

Faux, si vous ne pensez pas aux problématiques dès la conception, il y a une probabilité non nulle que vous vous cassiez les dents dessus lors de la maintenance!

Concernant votre demande initiale, je ne suis pas sûr de comprends le problème...
En général les liste de résultats sont paginées (=on n'affiche pas tous les résultats d'un coup mais seulement n résultats par pages, comme sur google par ex). Dans ce cas là, l'application (si elle a bien été réalisée) génèrera une requête qui sortira un sous-ensemble de n résultats du résultat "global". Bien sûr une requête sortant n résultats sur une table de 1000 enregistrements sera toujours plus rapide que sur une table contenant 100 000 enregistrements...
Ensuite pour optimiser le temps des requêtes, on utilise des index sur les attributs qui sont des critères de recherche.

[freud]

Re,

En général les liste de résultats sont paginées (=on n'affiche pas tous les résultats d'un coup mais seulement n résultats par pages, comme sur google par ex).

C'est bien cela, vous avez compris ma demande initiale.
Comme j'etait habitué à developper des BDD ne dépassant pas les dizaines de milliers, rapatrier en local le tout dans une grille et naviguer avec un composant DBnavigator comme on en trouve dans les RAD c'est rapide de de scroller ou de passer de page en page cela ne posait de problème d'autant que si on veut modifier une ligne dans la grille il suffit juste de double clicker par exemple et on affiche une fenêtre organiser en zone de texte et on fait ce que l'on veut, modifier/inserer. Mais, à l'idée d'avoir une BDD qui pourrait contenir quelque 700 000 lignes voire des millions alors je me suis dis que l'approche de présentation de données doit changer. Mais en fait, et je pense comme vous le dites (et je viens de m'arrêter la dessus) que, c'est de faire cela en paginant les données du sous-ensemble en utilisant le WHERE (peu importe le temps que ça prendra) pour passer de passer de pages en pages tout en proposant d'autres critères de rapatriement des données tels que par code, famille, marque, groupe d'article, etc... dans le cas d'une table des articles.

[Ecosmose]

Ce qu'a voulu dire ego, c'est que l'IHM et le référentiel métier en base devrait être orienté métier et utilisation et donc n'afficher que ce qui est pertinent. Une sélection de milliers d'élément doit être affinée pour une exploitation humaine pertinente.

Est il utile et nécessaire à tous les users d'accéder à tous les articles sur une seule page ? La structure des tables de données est elle pertinente ? ne peut elle pas être scinder avec une précision métier + détaillée ? (liaison relationnelle des catégorie d'articles, découpage en plusieurs tables des articles pour différencier ceux qui n'ont pas la même strcuture de données etc...)

Maintenant si la conception métier du schéma de la BD est correcte , on peut l'optimiser ou la restreindre par un schéma physique techniques pour ne justement pas être contraint à des balayages de tables volumineuses et des affichages surchargés surtout concernant les données statiques (qui n'évolue pas dans le temps). Exemple dans les données temporelles qui peuvent être énormes , les résultats peuvent être liées à un instant mais aussi catégorisée et agrégée en moyenne sur des périodes (mois , semaine, jour). Finalement tu travailles en dimension. Tu pourrais ainsi regrouper tes articles en catégories pour n'afficher que les catégories dans un premier temps...

Mais bon je serais curieux de voir la liste des 50 champs de la table article. Tu peux nous la fournir ?

Cotyé client, La pagination reste un bon moyen, mais je pense qu'une sélection par filtre et tri serait + pertinent pour ensuite n'afficher que la partie paginée. (clause where enrichie par les utilisateurs , voir des valeurs par défaut pour l'init de l'appli ) ... Ta couche DAO devra faire ce boulot d'optimisation avec les facteurs selectionnés dans l'IHM..