Discussion :

[Jean-Yves]

Bonjour,

Soit une application classique de gestion de devis, commandes, factures ,
commandes fournisseurs avec gestion de stock....
avec des fichiers liés qui ont une structure quasiment identique.

Que faut-il préférer au niveau analyse ? :
1) 1 fichier devis + 1 fichier factures + 1 fichier commandes+ ...
2) 1 seul fichier "documents" avec un champ "Type" (Devis/Facture/Commande ...)

Jusqu’à présent j'ai toujours opté pour des raisons de performances la solution1, mais c'est très lourd a maintenir,
aujourd'hui avec le serveur HF ou autres , les requêtes et la puissance des machines, je pense que le critère "performance" ne soit plus un critère valide.

J'ai toujours penser que la solution 2 permettait d'éviter la redondance de code , d'IHM et la mise en oeuvre de la programmation Objet de façon très aisée .
je pense arriver au million d’enregistrements en 5 ans environ , ce qui ne m’effraie pas si les index et les requêtes sont bien faites.

Qu'en pensez vous ?

Merci de vos réponses et de vos avis

[serendib]

Bonsoir Jean-Yves,

Pour moi, sans hésiter, la solution 2.
Côté performances, comme tu dis, en 2015, plus de problèmes.
Pour le codage, y'a pas photo.
Pour le principe, et dans le cas d'une gestion classique, c'est la logique.

Mais tout est fonction du type d'entreprise qui est gérée.
Biens de conso, services, bâtiment, etc...

En tout cas, bien que tout celà ne soit pas dans l'esprit du forum dev windev (mais pourquoi pas),
tu vas avoir des avis très divergents, et tu va lire sûrement beaucoup de choses pas toujours très vraies.

Tu as pris le risque, mais tu auras au moins des positions tranchées, à tord ou pas.
En tout cas ça changera un peu des questions basiques de plus en plus fréquentes sur les 3 forums consacrés à windev.

Avis très perso, je précise !

[darkWD]

Bonsoirs,

Moi je dit quelque chose entre les deux. bien évidement tout dépend de la politique de la société ou l'entreprise.

y'a bien des devis qui différent de la commande et bien des commande sans de vis et parfois même des factures qui ne dépendent pas d'une seul commande et des commandes avec plusieurs facture. Par exemple une commande qui sera livré sur plusieurs lots peut avoir plusieurs factures surtout si l'entreprise utilise le concept de BL/F. Et des fois un client passent une commande pour un article et dans les jours qui suivent passe une deuxième commande pour un autre et comme ça les deux commandes peuvent être livré en même temps avec une même facture.

et si on veut compliquer un peut les choses on peut prendre en considération les factures avoirs suite à quoi un nouveau produit (qui peut être différant) est livré au lieu du remboursement et ça ne nécessite pas de commande.

moi je préfère avoir une séparation au niveau physique. ce qui veut dire que je peut saisir une commande, ou, générer une commande depuis un devis. entre autre, copier les lignes du devis dans les lignes de la commande et mentionner le numéro du devis dans celle ci pour "éventuellement" pouvoir le consulter si besoin.

PS: pour consulter la facture vous ne devrai pas avoir à remonter les informations depuis le devis en passant par commande. Ce serai effectivement un peut trop.

[Hemgé]

y'a bien des devis qui différent de la commande et bien des commande sans de vis et parfois même des factures qui ne dépendent pas d'une seul commande et des commandes avec plusieurs facture. Par exemple une commande qui sera livré sur plusieurs lots peut avoir plusieurs factures surtout si l'entreprise utilise le concept de BL/F.

Bonsoir,

Quel problème pose cette chaîne documentaire logique par rapport à la structure du fichier ?
Il est évident que toutes les rubriques ne seront pas utilisées selon le type de document et il est aussi probable/possible que certaines rubriques auront des significations logiques différentes en fonction du type de document.

Pour le reste et en faisant court :

1. Facture directe (sans devis, ni bon de commande, ni ...) : enregistrement de structure standard avec la rubrique "Type" à "F" pour facture et aucun 'pointeur' vers un document précédent dans une chaîne logique.
2. Facture sur devis ou offre : d'abord un document de structure standard avec rubrique "Type" à "D" pour devis et aucun 'pointeur' vers un document précédent ; ensuite un second document, toujours de même structure standard avec rubrique "Type" à "F" pour facture et un 'pointeur' vers le document précédent dans la chaîne logique soit le devis.
   'Pointeur' : c'est sa cuisine interne et il n'y a pas à détailler ici sa nature, son type ou son organisation, sauf demande d'avis
3. etc ...

[Hemgé]

les 3 forums consacrés à windev.

Bonsoir serendib

Quel est "le" troisième forum consacré à Windev ?
Je suis régulièrement ceux de Developpez et PC soft.
J'en fréquente une kyrielle à l'occasion de recherches, mais je n'en connais pas un troisième aussi intéressant et encore actif.

Déjà merci

Hemgé

[fffttt]

bonjour

Vaste débat en effet.

Très intéressé par la question.
Je ne fais que du cas 1 (entêtes et lignes pour chaque type de document).
Bref des fois c'est la galère à maintenir.
Comment faites vous au passage?

Tenté par le cas 2 mais
(première question qui me vient à l'esprit)
comment gérer 1 facture regroupant plusieurs BL?
=> en mettant sur l'enregistrement une rubrique IdFacture

[fffttt]

Bonsoir serendib

Quel est "le" troisième forum consacré à Windev ?
Je suis régulièrement ceux de Developpez et PC soft.
J'en fréquente une kyrielle à l'occasion de recherches, mais je n'en connais pas un troisième aussi intéressant et encore actif.

Déjà merci

Hemgé

tunidev, groupgoogle sont pour ainsi dire morts.
wdforge est reparti mais ne semble pas prendre.

il y en a d'autres?

[Lo²]

Pour ma part, je suis pour l'école du 1) et j'avoue être surpris de cette idée de mettre tous les documents dans un seul fichier.

Concernant la maintenance de cette méthode, en quoi serait-elle plus lourde que de passer en méthode 2) ?

Concernant la puissance des machines, je trouve justement que cela ne devrait pas rentrer en compte dans ce choix, car une dérive dans la 'simplicité' du genre codage/modélisation bien bourrin qui sera 'caché' par la puissance de calcul est très vite arrivée.

Autre dérive sur cette méthode 2), certaines colonnes ne seront pas utilisées forcément pour tout les types de documents, QUID du fainéant qui va utiliser une de ces zones pour faire rapide, et qui ne correspondra pas du tout à l'intitulé de la colonne. Bonjour à ceux qui reprendront le code derrière
Ce cas peut aussi arriver sur la méthode 1) mais plus difficilement à mon sens.

[Jean-Yves]

Bonjour,
D'abord merci a tous, pour vos réponses.
Au vu de vos commentaires je suis vraiment tenté par la solution 2.
Concernant le chaînage documentaire comme le dit "Hemgé", cela ne me pose aucun problème , j'ai souvent dans mes fichiers des liens réflexifs (comme les familles et x sous familles).
c'est pourquoi une cde ->x bl -> x factures ou autre liens type Merise ne me posent aucun soucis avec un seul fichier générique et fichiers fils liés (entete_generique, lignes_générique)
et effectivement certaines rubriques ne seront utilisées que pour certains type de document.,
Dans mon code je ne n'accède plus en directe aux rubriques de fichiers pour les afficher (j'ai banni les ecranversfichier et cie) , je passe toujours par une classe intermédiaire et des requêtes, j'essaye au maximum de ne pas utiliser les contextes HF , sources de bugs si ils sont mal utilisés.
L'intérêt de la solution 2, permet a mon avis, aussi de mettre en place les classes abstraites (voir le polymorphisme qui prend ici tout son sens , un objet cde qui se transforme en bl... voir tutoriel sur ce site) de façon très facile, nom barbare pour certains , mais je vous l'assure a ceux qui sont réticents à la POO, ce n'est pas perdre son temps que de s'y intéresser de plus près et au final ce n'est pas très compliqué , il faut juste prendre un peu de recul. ces classes permettent justement de gérer les spécificités de chaque type de document ( cde ,facture) tout en gardant une ossature et la majorité des méthodes commune dans une seule classe et ce, en lien avec des fichiers communs générique .
Du coups un seule maintenance pour tous les documents :-)

[Jean-Yves]

Concernant la maintenance de cette méthode, en quoi serait-elle plus lourde que de passer en méthode 2) ?

Concernant la puissance des machines, je trouve justement que cela ne devrait pas rentrer en compte dans ce choix, car une dérive dans la 'simplicité' du genre codage/modélisation bien bourrin qui sera 'caché' par la puissance de calcul est très vite arrivée.

Autre dérive sur cette méthode 2), certaines colonnes ne seront pas utilisées forcément pour tout les types de documents, QUID du fainéant qui va utiliser une de ces zones pour faire rapide, et qui ne correspondra pas du tout à l'intitulé de la colonne. Bonjour à ceux qui reprendront le code derrière
Ce cas peut aussi arriver sur la méthode 1) mais plus difficilement à mon sens.

Bonjour,
par exemple les états d'impressions modifiables par etat et requete par les clients, sur la base d'un fichier commun , un seul état peut servir comme devis , cde, facture
franchement il n'y a pas grand chose qui diffère et une simple modification graphique est immédiatement répercuté sur l'ensemble des documents.
(utilisation des modèles d'états avec surcharge)
une seule requête pour avoir la liste des documents, une seule méthode de calcul de prix.....
cela parait peut être peu important mais sur une grosse application c'est beaucoup de temps de gagné , moi je développe un ERP , la GC n'est qu'une partie, j'ai déjà 200 fichiers et 150 fenêtres et une centaine de requêtes c'est pour cela que chaque ligne de code , ou élément de projet économisés est un gain de temps énorme , a mon avis......
Concernant les fainéants , cela reste vrai pour certains bidouilleurs... , mais bon ou je suis je pense pas que certains oseraient cela..... on le saurait vite.
Pour la puissance de calcul , si il y les bons index , les requêtes sont très performantes même sur des fichiers volumineux.

[serendib]

Bonsoir serendib

Quel est "le" troisième forum consacré à Windev ?
Je suis régulièrement ceux de Developpez et PC soft.
J'en fréquente une kyrielle à l'occasion de recherches, mais je n'en connais pas un troisième aussi intéressant et encore actif.

Déjà merci

Hemgé

Bonjour Hemgé,

Je pensais à tunidev, mais loin d'être aussi intéressant que les deux précités.
Un mec à la retraite qui le maintient sous perfusion en pondant du code tout fait à des débutants qui préfèrent attendre des heures
le dit code, plutôt que de s'autoformer en faisant le cours et en parcourant l'aide.
(Ceux-là même qu'on retrouve d'ailleurs parfois ici)
Et deux ou trois autres intervenants qui jouent la plupart du temps à je t'aime moi non plus.
Mais c'est amusant, un peu comme Acam, on y va pour rigoler, pas pour apprendre quoi que ce soit.