Discussion :

[b_reda31]

Bonjour,
je voudrai développer un petit logiciel de gestion de stock. J'ai commencé à me documenter sur les différentes stratégies de valorisations de stock :
- FIFO.
- CMUP après chaque entrée.
- CMUP après une période.

Je pense avoir bien compris ces concepts, cependant j'aurai besoin de quelques conseils pour leur mise en place d'un point du vue "base de données".

j'ai bien réfléchis à la question et je me retrouve face à un dilem...

On considère que nous sommes dans une stratégie : CMUP après chaque entrée

et pour faire simple, disons que nous avons deux tables :
Table Entrée : IdArticle,QtEntree,Prix Unitaire Achat, NumBonEntree ...etc.
et Table Sortie : IdArticle,QtSortie,Prix Vente,NumBonSortie,...etc.

Ma première hésitation concerne la valeur du CMUP, j'hésite entre deux options :
Option 1 : Ajouter le champs "CMUP" dans le fichier entrée, ainsi tous l'historique des valeurs du CMUP sera stocké dans le fichier "Entrée". Lors de l'enregistrement de chaque entrée on recalcule le cmup par rapport à l'ancien et au quantités (avant et après entrée).
je pense que cette option présente l'avantage d'être rapide lors de la génération d'état car aucun calcul n'est nécessaire, simple requêtes de sélection avec critères...
Par contre, s'il arrive que l'on enregistre une entrée antidatée,on devra alors mettre à jour touutes les entrée à partir de cette date (recalcul)....

Option 2 : : Ne pas stocker le CMUP dans l'entrée, il n y a ainsi aucune redondance, cependant en fonction du volume des entrées, les calculs lors de génération d'état peuvent prendre du temps...
Quelle méthode est la plus préconisée ? ou peut être que vous pouvez m'en proposer une autre ?



Merci par avance

Réda

[StringBuilder]

Stocker la valeur est effectivement tentant, car d'un point de vue performances, on peut s'attendre à avoir de meilleures performances.

Cependant, si demain il y a une correction d'entrée dans le passé, toutes les lignes de CMUP entre la date modifiée et maintenant seront fausses, et il faudra corriger en masse un grand volume d'information.

Une vue matérialisée me semble plus opportune (ou une colonne calculée indexée).

[SQLpro]

et pour faire simple, disons que nous avons deux tables :
Table Entrée : IdArticle,QtEntree,Prix Unitaire Achat, NumBonEntree ...etc.
et Table Sortie : IdArticle,QtSortie,Prix Vente,NumBonSortie,...etc.

Votre modèle est faux d'emblée. Dans un MCD chaque information, en dehors des clefs étrangères, ne doit figurer qu'une seule fois. Comme vous voulez modéliser directement au niveau physique vous faites n'importe quoi...

La table unique est la suivante :

• Clef, Date, IdArt, Qté, PUHT, IdBon...
• Clef est la clef primaire de la table.
• Date est la date du mouvement
• IdArt la clef étrangère du prdoduit visé
• Qté est la quantité (un réel) qui peut être positif => entrée, ou négatif => sortie

Puis faites deux vues qui vont présenter, l'une les entrées, l'autre les sorties.

Au niveau des calculs de stock, une simple fonction de fenêtrage suffit :
SUM(qté) OVER(PARTITION BY IdArt ORDER BY DATE)

Mais comme il est impératif de faire des inventaires, votre stock initial doit partir du dernier inventaire.

A +

[b_reda31]

Stocker la valeur est effectivement tentant, car d'un point de vue performances, on peut s'attendre à avoir de meilleures performances.
Cependant, si demain il y a une correction d'entrée dans le passé, toutes les lignes de CMUP entre la date modifiée et maintenant seront fausses, et il faudra corriger en masse un grand volume d'information.
Une vue matérialisée me semble plus opportune (ou une colonne calculée indexée).

Merci! je vais jeter un oeil sur "les vues matérialisées", je ne les ai jamais utilisées...

Votre modèle est faux d'emblée. Dans un MCD chaque information, en dehors des clefs étrangères, ne doit figurer qu'une seule fois. Comme vous voulez modéliser directement au niveau physique vous faites n'importe quoi...

La table unique est la suivante :

• Clef, Date, IdArt, Qté, PUHT, IdBon...
• Clef est la clef primaire de la table.
• Date est la date du mouvement
• IdArt la clef étrangère du prdoduit visé
• Qté est la quantité (un réel) qui peut être positif => entrée, ou négatif => sortie

Je vous remercie de votre rectification, je suis ravi que vous parlez de ce point car j'allais justement en parler dans un autre sujet (section Schéma), mais tant qu'on y est autant le faire ici ...

J'aimerai approfondir le fait que vous considérez que le premier modèle est faux.
Prenons un autre exemple si vous permettez. Sans trop entrer dans les détail de gestion, considérons que l'on désire mettre en place un SI qui permet de modéliser plusieurs types de pièces :
- Facture Client
- Facture Proforma Client
- Avoir Client


En fouillant un peu sur les logiciels existant (opensource, gratuit), je me suis rendu compte que l'on pouvait trouver deux façon de modéliser ce SI :

Méthode 1 : On considère un document quelque soit son type (Facutre, Proforma, Avoir) comme une seule entité, puisque les documents ont globalement les mêmes attributs (Clé Document,Date, Clé Client, Total TVA,Total TTC,...etc)
On ajoute cependant à l'entité "Document", l'attribut "TypeDocument" pour différencier les différents types de documents possibles.

Méthode 2 :
Créer une entité pour chaque type de document
1. Entité FactureClient
2. Entité FactureProformaClient
3. Entité AvoirClient

Dans la même façon de voir, si on reprend le premier exemple que j'ai donné (Entrée/Sortie)

On peut considérer une seule entité(méthode 1) : "Mouvement" qui regroupe à la fois les entrées et les sorties en différenciant les sorties par le signe négatif en quantité.

ou les eclater en deux entités (méthode 2)
1. Entrée
2. Sortie


Maintenant, dans l'absolu, pouvons-nous affirmer que la deuxième méthode est fausse ?
je me suis vraiment posé cette question avant de poster ce sujet, j'en suis arrivé à cette modeste conclusion :

- Mise à jour de la structure du fichier :
Dans le cas d'un mise à jour structurelle des données, par exemple ajouter un champ (attribut) au document
dans la première méthode il suffit simplement d'ajouter le champs dans l'entité "Document", par contre pour la deuxième méthode il faudrait reporter ce champ sur toutes les autre entités représentant les documents (Facture, FactureProforma,...) ce qui peut être assez lourd!

- Performance : d'un point du vue performance, je pense que la deuxième méthode est plus rapide, dans la mesure où les données sont répartis sur plusieurs fichiers. Si on veut récuperer les facture d'un client, il suffit de chercher dans le fichier "Facture" qui contient uniquement les facture et non pas dans un gros fichier contenant toutes pièces.

Je ne cherche pas à remettre en question ce que vous affirmez mais juste à comprendre pourquoi on peut d'emblée dire la deuxième méthode est fausse! (dans l'absolu)

Merci à vous.

[al1_24]

Peut-être qu'il ne faut pas penser en fichiers mais en tables. D'un point de vue physique les tables peuvent être indexées, ce qui accélère la recherche de lignes, voire partitionnées pour ne manipuler qu'une partie des lignes.
Il faut penser aussi la modélisation en fonction des opérations à effectuer : si devis, factures et avoirs sont dans trois tables distinctes, il faudra trois interrogations pour connaître toutes les opérations associées à un client. Par ailleurs, une facture a plusieurs lignes : devra-t-il y avoir une table pour les lignes de facture et une autre pour les lignes de devis ?
Je te laisse continuer à réfléchir sur le modèle le plus adapté...

[SQLpro]

Je vous remercie de votre rectification, je suis ravi que vous parlez de ce point car j'allais justement en parler dans un autre sujet (section Schéma), mais tant qu'on y est autant le faire ici ...

J'aimerai approfondir le fait que vous considérez que le premier modèle est faux.
Prenons un autre exemple si vous permettez. Sans trop entrer dans les détail de gestion, considérons que l'on désire mettre en place un SI qui permet de modéliser plusieurs types de pièces :
- Facture Client
- Facture Proforma Client
- Avoir Client


En fouillant un peu sur les logiciels existant (opensource, gratuit), je me suis rendu compte que l'on pouvait trouver deux façon de modéliser ce SI :

Méthode 1 : On considère un document quelque soit son type (Facutre, Proforma, Avoir) comme une seule entité, puisque les documents ont globalement les mêmes attributs (Clé Document,Date, Clé Client, Total TVA,Total TTC,...etc)
On ajoute cependant à l'entité "Document", l'attribut "TypeDocument" pour différencier les différents types de documents possibles.

Cel n'est pas dans les bonnes pratiques car cela conduit à un méta modèle qui possède tout un tas de limites logique et fonctionnelles. Et c'est un débat assez complexe, car le typage risque de devenir rapidement flou. Par exemple, pourquoi ne pas faire tout cela en XML ?

Méthode 2 :
Créer une entité pour chaque type de document
1. Entité FactureClient
2. Entité FactureProformaClient
3. Entité AvoirClient

C'est la bonne méthode, à condition d'introduire un héritage entre Facture et FactureProforma.

Dans la même façon de voir, si on reprend le premier exemple que j'ai donné (Entrée/Sortie)

On peut considérer une seule entité(méthode 1) : "Mouvement" qui regroupe à la fois les entrées et les sorties en différenciant les sorties par le signe négatif en quantité.

ou les eclater en deux entités (méthode 2)
1. Entrée
2. Sortie

Vous serez obligé de redondez certaines informations et donc vous violez les règles de modélisation qui supposent qu'il n'existe aucune redondance et que chaque information doit être mise une seule fois dans le modèle....

Maintenant, dans l'absolu, pouvons-nous affirmer que la deuxième méthode est fausse ?
je me suis vraiment posé cette question avant de poster ce sujet, j'en suis arrivé à cette modeste conclusion :

- Mise à jour de la structure du fichier :

Déjà vous faites une erreur énorme. Une table n'est pas un fichier. Une table est un objet logique qui est suffisamment plastique pour être modifié dan sa structure à la volée, ce qui n'est pas le cas d'un fichier qu'il faut entièrement reconstruire à chaque ajout d'info...

Dans le cas d'un mise à jour structurelle des données, par exemple ajouter un champ (attribut) au document

En matière de SGBDR on ne parle pas de champ... On parle d'attribut dans le MCD et de colonne dans le MPD. Les champs c'est une notion purement physique alors que nous sommes dans la pure logique. Parler de champs, c'est propre au cultivateur, au chirurgien (champ opératoire) ou encore dans les formulaire papier ou écran...

dans la première méthode il suffit simplement d'ajouter le champs dans l'entité "Document", par contre pour la deuxième méthode il faudrait reporter ce champ sur toutes les autre entités représentant les documents (Facture, FactureProforma,...) ce qui peut être assez lourd!

et en sus couteux et redondant !

- Performance : d'un point du vue performance, je pense que la deuxième méthode est plus rapide, dans la mesure où les données sont répartis sur plusieurs fichiers. Si on veut récuperer les facture d'un client, il suffit de chercher dans le fichier "Facture" qui contient uniquement les facture et non pas dans un gros fichier contenant toutes pièces.

Vous commettez une nouvelle erreur. Ce n'est pas au niveau de la modélisation que l'on se préoccupe des performances. Un SGBDR a été conçu pour manipuler des relations et il le fait vite et bien. Il faut donc respecter A LA LETTRE les principes de modélisation (pas de NULL, pas de redondances... etc). L'obsession qui consiste à essayer de se pencher sur le problème de performance à ce moment (la modélisation) ne peut que vous entrainer à produire l'inverse : un modèle imbécile, biscornu, peu évolutif, redondant et au final des performance de merde !
Il faut comprendre que la genèse des bases de données relationnelles est venu à la suite des problèmes de performances des modèles anciens (hiérarchique, "réseau" des années 60). Le principe étant une séparation ABSOLUE entre les aspects logique (la modélisation) et les aspects physique (le stockage, l'indexation...).

Je ne cherche pas à remettre en question ce que vous affirmez mais juste à comprendre pourquoi on peut d'emblée dire la deuxième méthode est fausse! (dans l'absolu)

Merci à vous.

En particulier dans votre cas, la table pourrait être partitionnée en deux si les performances ne sont pas au rendez-vous. Une partition contiendrait les entrées et l'autre les sorties.
Vous auriez ainsi la pertinence d'un modèle parfait et les performances les plus extrêmes...

C'est aussi pour cela qu'il existe deux métiers dans les SGBDR, celui de développeur et celui de DBA et l'un n'a absolument pas à se préoccuper des prérogatives de l'autre, ni même besoin de connaître intimement ce qui se passe de l'autre coté de la barrière. Cela a été voulu par Codd (l'inventeur des SGBDR) justement parce que les système précédents mélangeait les deux, ce qui posait des problèmes à la fois de logique de traitement et de performance !!!!

A +