Discussion :

[Coussati]

salut

je cherche depuis un moment a optimiser l'affichage de ma table dans un tableau, mais en vain

id | référence | taille | quantité

une référence procède plusieurs tailles et donc je ne veux pas devoir afficher à chaque fois la référence, ex :

1 | RF0214 | S | 10
2 | RF0214 | M | 15

j'aimerais afficher :

RF0214 | S | 10
| M | 15

je pense que c'est possible de faire en plusieurs requêtes, mais j'aimerais éviter un chargement trop important de la page

si vous voyez une meilleur disposition de la table, je reste ouvert

merci d'avance

[punkoff]

Bonjour,

Pour l'affichage ce n'est pas au SGBD de traiter ce genre de chose.

Mais plus à votre application qui présente les données.


Concernant votre gestion de stock, ce n'ai effectivement pas optimal.


Il vous faudrait à minimum 2 tables.. voir plus plus


Une solution simple :

Article-0,n----Decliné-----1,1-Art_Declinaison


Dans l'entité Art_déclinaison, vous pouvez mettre la taille, la couleur, ..... et le stock.





Mais idéalement il faudrait encore rajouter une entité mouvement de stock qui serait liée à votre table art_déclinaison.


Dans celle-ci vous n'aurez pas de stock en dur mais des entrée ou des sorties de stock ... (caractérisée par un chiffre positif ou négatif)

[Coussati]

c'est bien ce que je pensais la table doit être repenser

merci à vous

[SergioMaster]

Bonjour,

Que la table soit repensé : certes !
Connaissant bien le problème , GPAO pour une (des) usine(s) de fabrication de chaussures (et donc entre autre la gestion de son stock produits finis mais aussi matières premières) voici quelques tuyaux (pas forcément les meilleurs)

N.B. ce qui s'applique à la chaussure s'applique au textile , d'expérience pour avoir côtoyer les 2 mondes le textile est plus "simple"

il est vrai que pour bien? normaliser il faudrait une table modèle, une table article (modèle+couleur dans le monde de la chaussure on dit assortiment) et une table article_taille mais le poids (stockage données est souvent trop exorbitant à mon goût surtout que les nombre des pointures se compte entre 12 et 36.

Pour notre application (conçue an 1998 , à partir d'un existant beaucoup plus ancien ) nous avons fait le choix de gérer les tailles à l'intérieur de la table Modele (24 champs) un stock étant géré de la même manière (24 champs quantités , pointure selon la position) .
Le choix des 24 champs (et non 36) à fait longtemps débat , on aurait pu aussi à la place utiliser une table Grille_de_Pointures Standard (ici c'est l'existant qui à prévalu)

Pour ce qui est du SGBD, le choix s'est d'abord porté sur Interbase, remplacé depuis par Firebird . Ces SGBD permettent les tableaux à l'intérieur d'une table , cependant cette fonctionnalité n'a pas été retenue (manque de temps, de moyens , d'API pour les cumuls) .

pour ce qui est du stock outre les champs cités

Dans celle-ci vous n'aurez pas de stock en dur mais des entrée ou des sorties de stock ... (caractérisée par un chiffre positif ou négatif)

on a aussi les quantités inventaires , cependant un chiffre négatif INVENTAIRE+ENTREES-SORTIES doit être >= 0 , et le stock est en plus géré également en fonction de son rangement , ce qui donne une clé du style 'Modèle+Couleur+Emplacement'
Une table de suivi des mouvements à également été créée comme trace (mouvements d'entrées , de sorties, d'inventaire et ajustements + ou - )

Constatation de cette méthode : depuis plus de 13 ans maintenant elle fonctionne , malgré les évolutions des besoins (réservation d'articles, gestions es expéditions etc... ) elle est restée stable ! seul bémol il arrive de temps en temps que la grille de pointures sur un modèle change , la transmission des consignes aux nouveaux venus n'étant pas toujours faite il y a eu quelques couacs (une trentaine en 13 ans, soit une moyenne de 2 par collection pas de quoi fouetter un chat) .
Depuis quelques temps cependant nous sommes confronté aux tailles "internationales" , le même article+pointure ayant des libelles différents selon les pays qu'un tableau de pointure ne peut convertir tout à fait à la perfection (à cause de chevauchements) , mais je m'éloigne du sujet .

Une ré-écriture de l'application est envisagée , aussi j'aimerais bien connaitre votre sentiment la méthode utilisée