Discussion :

[Ponset]

Bonjour,

Je travail actuellement à la conception d'une base de donnée pour petit ERP web pour une entreprise travaillant dans le textile.

Ma question porte sur la gestion des collections et des dates de validités de mon entité Article. Pour simplifier, j'ai 2 entités "produits" une pour les articles personnalisés et fabriqués et une 2ième pour les articles qu'ils achètent a des grossistes.

J'ai donc un certain nombre de contraintes autours des ces entités :

"Devis", "Ligne_devis", "Commande", "Ligne_commande", "Bon_livraison", "Ligne_livraison"... etc qui sont liées à mes 2 entités "produit_negoce" et "références".

Je me demande comment gérer les articles inactif (car ils ont dépassé la date de validité) et le changement de collection. Mes contraintes sont pour l'instant toutes en "RESTRICT". Je pensais laisser tous les "vieux" articles en base par rapport aux informations contenu dans les parties "commande", "bon_livraison" et "facture" mais au bout d'un moment il faudra bien que je nettoie un peu la table pour éviter une baisse de performance.

Je n'arrive pas à trouver des exemple concret de suppression d'articles tout en conservant un trace de mes commandes et factures... Puisque forcément en supprimant mes articles les clés étrangères de Ligne_commande, Ligne_facture... etc deviendront obsolètes.

Merci !

[Richard_35]

Bonjour Ponset,

Juste pour mon info, pourquoi ne pas avoir qu'une seule entité "Article" avec une information sur sa provenance interne/externe ?

Sinon, pour ta problématique de fond, tu pourrais prévoir :

- des entités "Historique", avec autant d'entité "Historique" que d'entité que tu veux historiser ;
- un petit trigger qui, avant chaque suppression d'article (qui aura été historisé) :

. écrit, dans les entités "Historique" qui vont bien, les infos des entités "mère" qui vont bien ;
. supprime les enregistrements des entités "mères" ;
. supprime l'article.

[f-leb]

bonsoir,

...Je n'arrive pas à trouver des exemple concret de suppression d'articles tout en conservant un trace de mes commandes et factures... Puisque forcément en supprimant mes articles les clés étrangères de Ligne_commande, Ligne_facture... etc deviendront obsolètes.

Simplement en mettant en œuvre une entité ArticleInactif selon le MCD:

Article----0,1-----etre------1,1-----ArticleInactif

ArticleInactif(#idArticle, DateInactifDepuis, Motif, ...)

[Ponset]

Bonjour Ponset,

Juste pour mon info, pourquoi ne pas avoir qu'une seule entité "Article" avec une information sur sa provenance interne/externe ?

Sinon, pour ta problématique de fond, tu pourrais prévoir :

- des entités "Historique", avec autant d'entité "Historique" que d'entité que tu veux historiser ;
- un petit trigger qui, avant chaque suppression d'article (qui aura été historisé) :

. écrit, dans les entités "Historique" qui vont bien, les infos des entités "mère" qui vont bien ;
. supprime les enregistrements des entités "mères" ;
. supprime l'article.

bonsoir,



Simplement en mettant en œuvre une entité ArticleInactif selon le MCD:

Article----0,1-----etre------1,1-----ArticleInactif

ArticleInactif(#idArticle, DateInactifDepuis, Motif, ...)

Bonjour à vous deux et merci de votre réponse.

Je vous reponds à tous les 2 en même temps.

Je n'ai pas qu'une seule entité article parce que mon schéma un peu complexe. Par rapport à l'activité de l'entreprise, j'ai du faire une entité article (pour les articles personnalisés et fabriqués) ses articles ont des groupes (tailles, couleurs, options), des attributs et des références générées par la combinaison des attributs de ces groupes qui me permettent d'avoir un SKU et des stocks.

A ça vient s'ajouter une certain nombres d'articles qu'ils achètent à un grossiste qui sont gérer à part dans une autre table la fameuse "produit_negoce".

Je n'avais pas pensé à faire une table d'archive avec les même relations que la table Article afin de les archiver. C'est a priori la meilleur solution. La réponse de f-leb va dans ce sens aussi mais par contre j'ai déjà un booléen actif/inactif pour l'article qui me sert à faire apparaître ou pas l'article dans la commande (selon la date de fin de validité de l'article ou la volonté de l'utilisateur). Mais là aussi il y a des exceptions, il peut y avoir des commandes en "reassort" c'est dire avec un article qui a déjà été commander par un client à un tarif spécifique.

Bref merci pour vos idées.

[CinePhil]

mais au bout d'un moment il faudra bien que je nettoie un peu la table pour éviter une baisse de performance.

Si ta BDD est correctement modélisée et implémentée, même avec 100 000 articles nouveaux par an, tu peux attendre 10 ans avant de commencer à rencontrer des petits problèmes de ce côté là !