Discussion :

[Fmfib]

Bonjour

J'ai 1 questions à vous proposer je veux savoir vos expériences

Je veux garder un seul fichier (.fic) dans lequel j'enregistre les achats(Fournisseurs) et les ventes (Clients) et le fichier détail de ligne au lieu de créer (utiliser) 2 fichiers l'un pour les ventes et l'autre pour l'achat.
Est ce que cette méthode me donne une flexibilité, rapidité au niveau d'affichage des données et autre traitement par exemple au moment de statistique au lieu de parcourir 2 fichiers je parcours qu'un seul ?

Quel est votre avis?

Merci

[serendib]

Tout dépends du contexte et du type d'entreprise.
Mais les achats et les ventes sont deux choses bien distinctes par définition.
La structure des lignes n'est pas identiques.
Donc le fichier sera plus gros en taille que deux, puisqu'il y aura des rubriques différentes, donc inutiles dans l'un ou dans l'autre.
Et quid de la numérotation ?
Bref, pour moi, une très mauvaise idée.

[Fmfib]

Merci de ton retour

Après une recherche je trouve que Sage utilise cette conception (Un seul fichier au lieu de 2)

[philouZ]

Nous on utilise q'un fichier pour tous les documents et ça fonctionne très bien. il faut juste conceptualiser correctement sur papier.

Les données en elles mêmes ne sont pas si différentes entre les achats et les ventes, voir même pour une grosse partie ce sont les mêmes.

[frenchsting]

Je rejoins Serendib. Il vaut mieux avoir 2 fichiers :

- Achat et ventes sont des choses différentes (même si des données peuvent être communes)
- Tu vas avoir des rubriques inutiles selon que tu es en achat ou en vente.
- Tu vas ralentir tes temps de traitement 2 fois plus vite pour les entêtes... et je ne te parle même pas des lignes...

[serendib]

Je me répète : Tout dépends du contexte et du type d'entreprise.

Fmfib,
Tu devrais nous en dire plus sur le type de l'entreprise et le type de produits.
S'il s'agit d'une petite boite qui vends un produit spécifique pour lequel le fournisseur est toujours le même,
par exemple, pourquoi pas (à la limite !).

Sinon, pour moi, c'est pas une bonne idée.

[philouZ]

temps de traitement 2 fois plus vite pour les entêtes

Tu te bases par rapport à quoi pour 2 fois plus vite ???

[philouZ]

C'est comme si on, disait qu'un fournisseur c'est pas un client. Or une table de tiers unique pour les clients et les fournisseurs est une très bonne chose. On évite de dupliquer des données. Les quelques spécificités peuvent facilement être traitées.

Une vente ou un achat, c'est exactement la même chose. Il y en a un mouvement en entrée dans un cas et un mouvement en sortie dans l'autre, c'est la seule différence qu'il puisse y avoir entre les 2.

[tbc92]

Imaginons un supermarché. Un achat, c'est en fait une commande , une date de livraison prévue... il ne va pas acheter une boite de petits pois, mais une palette contenant 14 boites de petits pois ...
Alors qu'une vente, il va la constater après coup, quand le client passe en caisse.
A mon avis, il a 2 fichiers qui n'ont rien à voir pour gérer les achats d'une part, et les ventes d'autre part. Le service 'comptabilité fournisseur' est d'ailleurs un service à part entière dans ces magasins.

Dans d'autres configurations, on peut très bien imaginer des situations où les besoins sont les mêmes pour gérer les achats et les ventes. Et ça peut simplifier les choses d'avoir les différentes informations dans un même fichier.

Si c'est un programme qui doit te prendre 2 ou 3 ans de travail, parce que tu sais qu'il y aura plein de cas tordus , plein de trucs différents à gérer, alors pars sur 2 fichiers différents.
Mais si c'est pour un besoin basique, à faire en une semaine, et qui n'évoluera pas, pars sur un seul fichier.

[Fmfib]

Bonjour

J'explique en plus :

Les fournisseurs ne sont pas toujours des clients et vice versa (Parfois on tombe sur quelques fournisseurs se sont des clients).
Les informations existant dans la table ACHAT ne sont pas totalement en commun avec la table VENTES .
Notre application est standard, plusieurs sociétés avec différentes activés utilisent notre application et chaque société sa politique de travail.
les 2 fichiers peuvent avoir plus de 2 Go de données (Archives 2017,2018,2019,...), donc c'est gourmand.

[philouZ]

La question est de savoir s'il y a plus de choses en commun ou plus de différences. C'est ce qui va définir ton modèle de données. si tu as 2 colonnes de différence, une table suffit, si tu as 2 colonnes communes et 20 différentes alors il faut 2 tables.

La taille du fichier importe peu. Très honnêtement un fichier de 2 Go n'est pas un fichier très important.

[tbc92]

Ce que je vois, c'est tu as une application qui existe.
Et ce que tu envisages c'est de modifier le coeur de l'application.

Stop.

Si tu as 2 fichiers séparés aujourd'hui, alors la bonne solution, c'est de travailler avec 2 fichiers.
Si les achats et les ventes sont dans le même fichier aujourd'hui, alors la bonne solution, c'est d'avoir tout dans un même fichier.

En d'autres mots, la bonne solution, c'est de ne rien changer.
Surtout qu'ici, tu as une grosse application, et tu as 2 fichiers séparés pour achats et Ventes, et que le modèle qui paraît le plus adapté pour les grosses applications, c'est d'avoir 2 fichiers séparés.

Eventuellement, ce que tu peux faire, c'est d'utiliser une ou plusieurs vues
- fichier ACHATS, inchangé
- Fichier VENTES , inchangé
- Vue ACHATS_VENTES : dans l'analyse, tu peux créer une vue, j'imagine que tu peux faire une vue du type select ... from achats UNION select ... from Ventes
Et tu pourras utiliser cette vue en LECTURE.

Peut-être même que tu peux utiliser cette vue pour les mises à jour de fichiers... je n'en sais rien, mais dans ma logique, une vue ne sert qu'à faciliter la lecture.

[Fmfib]

Merci tbc92 pour tes explications

1 Je veux modifier le concept de notre application afin améliorer la vitesse d'affichage (Pour l'instant l’affichage est acceptable) notre application ca tourne depuis 2014
2 Actuellement j'ai 2 fichiers séparés
3 Oui je veux utiliser les vues, mais est ce que les vues accélère la vitesse d'affichage?

Je voudrais utiliser les thread et les tache parallèles mais sincèrement j'ai pas encore les exploiter dans notre application, donc j'ai pas encore une expérience assez approfondie la dessus

[tbc92]

Pour les questions de performance, je pense que les solutions proposées ne vont rien changer. Même les vues ne vont rien changer.

Peut-être que pour améliorer la performance, il va falloir changer l'analyse... mais c'est vraiment la dernière hypothèse à envisager.
Difficile de t'aider avec les informations que tu donnes, tu dis peu de choses.

La première piste que je vois, c'est hReindexe(). Il faut faire régulièrement hReindexe() sur chacun des fichiers. J'ai eu des cas où les temps de traitement ont été divisés par 10 suite à un hReindexe(). Et dans hReindexe(), on peut préciser un certain paramètre, qui va optimiser soit les lectures, soit les écritures. A toi de bien doser. Mais ce paramètre joue peu.

La 2ème piste, c'est HFClassic ou HFClientServeur.
Avec 2Go de données, j'imagine que tu es en ClientServeur. Si ce n'est pas le cas, il faut faire des tests pour passer en ClientServeur.

L'autre changement que j'envisagerais, c'est de passer de HF vers PostGreSQL ou vers MySQL. Ca aussi, ça peut se faire sans tout refaire, moins de changement a priori que si tu changes ton analyse.

Plus plein d'autres options (des disques plus rapides, utiliser du RDC, etc )

Et si rien de tout ça ne marche, revoir l'analyse.
Mais je ne vois vraiment pas en quoi revoir l'analyse et regrouper les fichiers achats et ventes pourrait accélérer les traitements.

[Fmfib]

Bonjour tbc92

1 Je suis en HFClientServeur
2 Chaque minuit je lance la réindexation via le cente (Tache planifié)
3 Pour améliorer la performance, il va falloir changer l'analyse. Que dois je faire dans l'analyse? quel type de changement par exemple ?
4 Je veux regrouper les 2 fichiers : Parce que j n'ai pas un ficher de stock dans lequel je stock la quantité finale, alors pour calculer le stock je parcours les fichiers pour chaque article en utilisant 2 requêtes paramétrée l'une pour le fichier AChat et l'autre pour le fichier Vente

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//Le traitement qui prend beaucoup du temps c'est le calcule du stock
Stock =( ACHAT.Qte + VENTE.QTEAvoirClient ) - (VENTE.Qte+ACHAT.QteAvoirFournisseur)

Pour un seule article ne pose pas de problème de vitesse c'est rapide, mais lors l'utilisateur demande un état pour tous les articles (Ex: Etat d’évaluation du stock) là il faut attendre entre 20 min et 45 min et cela dépend de la taille de BDD s'elle est grande, le temps peut dépasser 45 min

C'est tu assez du temps je peux te donner un accès via anydesk

Merci encore une fois et bonne weekend

[tbc92]

Stock =( ACHAT.Qte + VENTE.QTEAvoirClient ) - (VENTE.Qte+ACHAT.QteAvoirFournisseur)

Pour un seule article ne pose pas de problème de vitesse c'est rapide, mais lors l'utilisateur demande un état pour tous les articles (Ex: Etat d’évaluation du stock) là il faut attendre entre 20 min et 45 min et cela dépend de la taille de BDD s'elle est grande, le temps peut dépasser 45 min

J'imagine que l'instruction en question elle est dans une portion de code de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Pour chaque produit
  hlitrecherche (achat) 
  hlitRecherche (Vente)
  Stock = ...
Fin

En regroupant les 2 fichiers en un seul, au mieux, tu diviseras les temps par 2 ... et encore, c'est très optimiste.

Pour cet état, as-tu envisagé une requête SQL ?

[Fmfib]

Pour cet état, as-tu envisagé une requête SQL ? Oui

[tbc92]

Oui ... et ça a donné quoi ? Ca n'a pas donné des temps satisfaisants ? Normalement, sur des volumes comme ça, une requête SQL devrait donner des résultats très satisfaisants. Mais effectivement, la requête qui convient doit être un peu complexe.

[philouZ]

@Fmfib : Si tu avais exposé ton problème plus tôt, je ne t'aurais jamais dirigé vers le regroupement en 1 seule table mais de revoir ton analyse pour la gestion de ton stock.

Voilà ce qui se fait le plus fréquemment. Tu crées une table pour les mouvements qui va contenir à minima:

• ID
• ID article
• Date Heure du mvt
• Qté (+ pour entrée, - pour sortie)

De cette manière tu peux très facilement recalculer ton stock pour tes articles grâce à une requête de regroupement. Tu verras les temps réduire comme peau de chagrin.

Je te conseille également de prévoir une table pour les inventaires (global, tournant,...) de cette manière tu pourras recalculer tes stocks à partir d'une certaine date et non depuis le début de la création de l'article.

A côté de ça, je sens d'ici la grosse boulette, du genre je lance une requête par article au lieu de lancer 2 requêtes de regroupement et de faire le parcours en mémoire.

[tbc92]

Et même, pourquoi lancer 2 requêtes.

Une requête qui lit les 2 fichiers, ça peut le faire :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
select P.id_produit, P.desc_produit, P.stock_initial + coalesce(A.qtt,0) - coalesce( V.qtt,0) as stock_final
from Produit P ,
(select id_produit, sum(qtt) as qtt from achat ) A,
(select id_produit, sum(qtt) as qtt from vente ) V
where A.id_produit (+) = P.id_produit
and V.id_produit (+) = P.id_produit