Modélisation d'une information de suivi de stock
Résolu/Fermé
pulls
Messages postés
136
Date d'inscription
mercredi 30 décembre 2009
Statut
Membre
Dernière intervention
13 septembre 2023
-
26 juil. 2013 à 21:58
pulls Messages postés 136 Date d'inscription mercredi 30 décembre 2009 Statut Membre Dernière intervention 13 septembre 2023 - 9 août 2013 à 14:15
pulls Messages postés 136 Date d'inscription mercredi 30 décembre 2009 Statut Membre Dernière intervention 13 septembre 2023 - 9 août 2013 à 14:15
A voir également:
- Modélisation d'une information de suivi de stock
- Suivi des modifications word - Guide
- Information d'identification réseau - Guide
- Suivi colis - Guide
- Logiciel de gestion de stock, inventaire et facturation gratuit - Télécharger - Comptabilité & Facturation
- Suivi conso sfr #123# - Forum SFR
8 réponses
Ichigo D Labu
Messages postés
29
Date d'inscription
samedi 27 juillet 2013
Statut
Membre
Dernière intervention
9 août 2013
1
27 juil. 2013 à 12:21
27 juil. 2013 à 12:21
Bonjour,
je ne suis pas d'accord avec toi sur les nom de table : je crois que codification et affectation désigne la même opération. ensuite la validation est une opération distinct c'est pourquoi on va ajouter une table "Validation" pour la table Réparation je suis d'accord mais je n'ai as compris l'utilité de la table Instance !?
A mon avis soit tu crée une autre table nommé "Retour" ou bien tu regroupe la "retour" et "réparation" dans une même table avec un champ "Type" pour faire la différence ( moi je suis avec la 1er solution elle est plus simple)
Pour les autre Table les champs seront comme suite :
Codification :
- NA : numéro d'affection ( tu met le numéro de série carrément )
- Date d'affection
- Agent ( celui qui a fait l'affectation si tu veux
-...plus d'autre champs qui pourront te servir après.
Validation :
-NV : Numéro de validation
-NA : Numéro d'affectation (clé étrangère)
-ResponsableS: Resposable de service qui va valider.
-Vendeur:a qui on a remis les téléphone.(numéro o nom c'est ton choix )
Réparation:
-NR:Numéro de réparation.
-NA : Numéro d'affectation (clé étrangère)
-NV : numéro de validation pour laissé une trace sur qui a fait la validation.
-DateR:Date de la réparation.
-Techenicien:Celui qui a fais la réparation(si tu veux)
Retour:
-NRt:Numéro de retour.
-NA : Numéro d'affectation (clé étrangère)
-NV : numéro de validation pour laissé une trace sur qui a fait la validation.
-DateR:Date de Retour.
Je pense que avec cette modélisation tu peux créer des requêtes pour faire le suivie des téléphone.
Bonne chance
je ne suis pas d'accord avec toi sur les nom de table : je crois que codification et affectation désigne la même opération. ensuite la validation est une opération distinct c'est pourquoi on va ajouter une table "Validation" pour la table Réparation je suis d'accord mais je n'ai as compris l'utilité de la table Instance !?
A mon avis soit tu crée une autre table nommé "Retour" ou bien tu regroupe la "retour" et "réparation" dans une même table avec un champ "Type" pour faire la différence ( moi je suis avec la 1er solution elle est plus simple)
Pour les autre Table les champs seront comme suite :
Codification :
- NA : numéro d'affection ( tu met le numéro de série carrément )
- Date d'affection
- Agent ( celui qui a fait l'affectation si tu veux
-...plus d'autre champs qui pourront te servir après.
Validation :
-NV : Numéro de validation
-NA : Numéro d'affectation (clé étrangère)
-ResponsableS: Resposable de service qui va valider.
-Vendeur:a qui on a remis les téléphone.(numéro o nom c'est ton choix )
Réparation:
-NR:Numéro de réparation.
-NA : Numéro d'affectation (clé étrangère)
-NV : numéro de validation pour laissé une trace sur qui a fait la validation.
-DateR:Date de la réparation.
-Techenicien:Celui qui a fais la réparation(si tu veux)
Retour:
-NRt:Numéro de retour.
-NA : Numéro d'affectation (clé étrangère)
-NV : numéro de validation pour laissé une trace sur qui a fait la validation.
-DateR:Date de Retour.
Je pense que avec cette modélisation tu peux créer des requêtes pour faire le suivie des téléphone.
Bonne chance
pulls
Messages postés
136
Date d'inscription
mercredi 30 décembre 2009
Statut
Membre
Dernière intervention
13 septembre 2023
3
29 juil. 2013 à 10:44
29 juil. 2013 à 10:44
Merci de vouloir m'aider,
je vous remercie mille fois de votre disponibilité.
En effet , je pense qu'il y a un malentendu sur les tables codification et affectation. En effet:
- Codification consiste à enregistrer le numéro de série du téléphone dans la base de données, c'est le service de liaison qui fait ce travail, le travail du magasinier se limite seulement à sortir, à la demande, un lot de téléphone et de mettre à sa disposition.
- Affectation consiste à donner un téléphone à un vendeur, un téléphone peut bien être codifier sans être affecter.
Vous voyez bien qu'il ne s'agit pas de la même opération.
je ne sais pas si vous êtes du même avis avec moi qu'il faut 2 tables distinctes?
Cordialement
je vous remercie mille fois de votre disponibilité.
En effet , je pense qu'il y a un malentendu sur les tables codification et affectation. En effet:
- Codification consiste à enregistrer le numéro de série du téléphone dans la base de données, c'est le service de liaison qui fait ce travail, le travail du magasinier se limite seulement à sortir, à la demande, un lot de téléphone et de mettre à sa disposition.
- Affectation consiste à donner un téléphone à un vendeur, un téléphone peut bien être codifier sans être affecter.
Vous voyez bien qu'il ne s'agit pas de la même opération.
je ne sais pas si vous êtes du même avis avec moi qu'il faut 2 tables distinctes?
Cordialement
Ichigo D Labu
Messages postés
29
Date d'inscription
samedi 27 juillet 2013
Statut
Membre
Dernière intervention
9 août 2013
1
Modifié par Ichigo D Labu le 30/07/2013 à 09:35
Modifié par Ichigo D Labu le 30/07/2013 à 09:35
Bonjour,
Oui maintenant que vous avez mentionner que les deux opération sont réalisés par deux services différent, deux tables distinct sont favorables
le schéma des autres tables vous convient-t-il ?
Cordialement.
Oui maintenant que vous avez mentionner que les deux opération sont réalisés par deux services différent, deux tables distinct sont favorables
le schéma des autres tables vous convient-t-il ?
Cordialement.
pulls
Messages postés
136
Date d'inscription
mercredi 30 décembre 2009
Statut
Membre
Dernière intervention
13 septembre 2023
3
30 juil. 2013 à 12:29
30 juil. 2013 à 12:29
Merci,
le schéma que vous m'avez proposé est très intéressant , puisque je pourrais faire mes requêtes en sortie suivant les objectifs. Mais j'ai une préoccupation.
Je vous ai expliqué que quand un produit sort du magasin, il doit être codifié ( enregistrement de la série) ensuite une autre opération consiste à affecter ce produit au vendeur. Mais je ne sais pas à quelle table, lié le champ codification et le champ affectation. Pour être plus clair voici une partie de schémas existant et en exploitation. il s'agit d'une application de gestion de stock:
1er module déjà en exploitation
PRODUIT ( idProduit, libelle, idFournisseur#)
MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit#, expediteur, destinataire)
DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables, car on distingue 2 types de produit au magasin, les consommables et le materiel comme le téléphone, les consommables sont directement consommé sur le terrain alors que le matériel a une durée de vie et c'est ce suivi du materiel sur le terrain qui fait l'objet du 2ème module de l'application.
2ème module à intégrer
CODIFICATION( idCodification, dateCodification, agent, idMouvement#) // ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant. Je ne sais pas si vous trouvez cela logique?
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idCodification#)
VALIDATION ( idValidation, idCodification#, responsable) // j'ai lié la validation à la codification, je ne sais pas si c'est logique?
RETOUR( idRetour, idAffectation#, dateRetour)
REPARATION( idReparation, idRetour#, dateReparation, technicien)
NB: les clés étrangères sont suivies d'une dièse
Voilà donc le schémas que je propose avec l'aide de Tchigo. s'il vous plait, je voudrais que vous m'aidiez à relever les éventuelles incohérences; il s'agit de ma première application après mes études et je suis en stage préemploi.
Cordialement.
le schéma que vous m'avez proposé est très intéressant , puisque je pourrais faire mes requêtes en sortie suivant les objectifs. Mais j'ai une préoccupation.
Je vous ai expliqué que quand un produit sort du magasin, il doit être codifié ( enregistrement de la série) ensuite une autre opération consiste à affecter ce produit au vendeur. Mais je ne sais pas à quelle table, lié le champ codification et le champ affectation. Pour être plus clair voici une partie de schémas existant et en exploitation. il s'agit d'une application de gestion de stock:
1er module déjà en exploitation
PRODUIT ( idProduit, libelle, idFournisseur#)
MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit#, expediteur, destinataire)
DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables, car on distingue 2 types de produit au magasin, les consommables et le materiel comme le téléphone, les consommables sont directement consommé sur le terrain alors que le matériel a une durée de vie et c'est ce suivi du materiel sur le terrain qui fait l'objet du 2ème module de l'application.
2ème module à intégrer
CODIFICATION( idCodification, dateCodification, agent, idMouvement#) // ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant. Je ne sais pas si vous trouvez cela logique?
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idCodification#)
VALIDATION ( idValidation, idCodification#, responsable) // j'ai lié la validation à la codification, je ne sais pas si c'est logique?
RETOUR( idRetour, idAffectation#, dateRetour)
REPARATION( idReparation, idRetour#, dateReparation, technicien)
NB: les clés étrangères sont suivies d'une dièse
Voilà donc le schémas que je propose avec l'aide de Tchigo. s'il vous plait, je voudrais que vous m'aidiez à relever les éventuelles incohérences; il s'agit de ma première application après mes études et je suis en stage préemploi.
Cordialement.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Ichigo D Labu
Messages postés
29
Date d'inscription
samedi 27 juillet 2013
Statut
Membre
Dernière intervention
9 août 2013
1
30 juil. 2013 à 13:57
30 juil. 2013 à 13:57
Bonjour,
Pour la table Codification je pense aussi que la lier a la table Mouvement est logique puisque le lien avec la table Produit est direct.
Cependant si j'ai bien compris le sens de la démarche qui est :
Codification -> Validation -> Affectation -> Retour -> Réparation
La logique dis que les clés étrangères migrent dans le même sens de cela les Tables Validation et Affectation seront comme suite :
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idValidation#)
VALIDATION ( idValidation, idCodification#, responsable)
Pour le reste je pense que c'est Ok.
Je répondrait a vos question aussi tôt que je le pourrais.
Bonne chance.
Pour la table Codification je pense aussi que la lier a la table Mouvement est logique puisque le lien avec la table Produit est direct.
Cependant si j'ai bien compris le sens de la démarche qui est :
Codification -> Validation -> Affectation -> Retour -> Réparation
La logique dis que les clés étrangères migrent dans le même sens de cela les Tables Validation et Affectation seront comme suite :
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur, idValidation#)
VALIDATION ( idValidation, idCodification#, responsable)
Pour le reste je pense que c'est Ok.
Je répondrait a vos question aussi tôt que je le pourrais.
Bonne chance.
pulls
Messages postés
136
Date d'inscription
mercredi 30 décembre 2009
Statut
Membre
Dernière intervention
13 septembre 2023
3
30 juil. 2013 à 14:48
30 juil. 2013 à 14:48
Merci Tchigo,
votre remarque sur la structure de la table AFFECTATION est vraiment pertinente, c'est la clé de la table validation qui doit migrer dans cette table.
Je voudrais completer le sens de ma démarche que tu as mis en evidence:
Codification -> Validation -> Affectation -> Retour -> Réparation
------------------------------------------------------- | --------- | ------------
--------------------------------------------------------V ---------V-------------
------------------------------------------ ------------- stockage----------------
( pointillé à ignorer, juste pour caler les flèches descendantes)
En effet les téléphones retourné en bon état , parce que le vendeur est indisponible, sont stocké au service de liaison en attente d'une nouvelle affectation; et justement c'est pour cela que j'avais créé la table INSTANCE; car un téléphone retourné en bon état ou un téléphone qui sort de la réparation doit être stocké quelque part, d'ou la nécessite de la table INSTANCE.
Je ne sais pas si vous êtes du même avis que moi.
Une autre préoccupation s'il vous plait. Comment les téléphone de la table INSTANCE peuvent être de nouveau reaffectés, si je crée une clé étrangère idInstance# dans la table AFFECTATION, ça doit former une boucle; et je crois avoir lu quelque part que ce n'est pas recommandé. Qu'est-ce que vous en pensez s'il vous plait?
Merci
Cordialement.
votre remarque sur la structure de la table AFFECTATION est vraiment pertinente, c'est la clé de la table validation qui doit migrer dans cette table.
Je voudrais completer le sens de ma démarche que tu as mis en evidence:
Codification -> Validation -> Affectation -> Retour -> Réparation
------------------------------------------------------- | --------- | ------------
--------------------------------------------------------V ---------V-------------
------------------------------------------ ------------- stockage----------------
( pointillé à ignorer, juste pour caler les flèches descendantes)
En effet les téléphones retourné en bon état , parce que le vendeur est indisponible, sont stocké au service de liaison en attente d'une nouvelle affectation; et justement c'est pour cela que j'avais créé la table INSTANCE; car un téléphone retourné en bon état ou un téléphone qui sort de la réparation doit être stocké quelque part, d'ou la nécessite de la table INSTANCE.
Je ne sais pas si vous êtes du même avis que moi.
Une autre préoccupation s'il vous plait. Comment les téléphone de la table INSTANCE peuvent être de nouveau reaffectés, si je crée une clé étrangère idInstance# dans la table AFFECTATION, ça doit former une boucle; et je crois avoir lu quelque part que ce n'est pas recommandé. Qu'est-ce que vous en pensez s'il vous plait?
Merci
Cordialement.
Ichigo D Labu
Messages postés
29
Date d'inscription
samedi 27 juillet 2013
Statut
Membre
Dernière intervention
9 août 2013
1
31 juil. 2013 à 03:18
31 juil. 2013 à 03:18
Salut,
Si j'ai bien compris la Table Instance a pour But de spécifier les téléphones non affecter ?
A mon avis pas besoin d'une Table instance!rien n'empêche que les Tables Retour et Réparation elles même peuvent nous donner l'information qu'on veux puisque un téléphone qui existe dans l'un de ces Tables est d'office un téléphone en instance a condition qu'il n'ai qu'une seul et unique affectation.une requête fera l'affaire.
en ce qui concerne le cas ou un téléphone subit une 2éme affectation, je ne sais pas qu'elle est la procédure mais on principe une téléphone ne peut subir une second affectation que si il est déjà passer par la table Retour ou Réparation, mais la table comme elle est maintenant permettra de faire une second affectation puisque on a q'une seul clé Primaire IdAffectation et le champ Date fera indice pour différencier les affectations d'un même téléphone a condition bien sure que l'affectation n'est possible qu'une seul fois par jour.tous dépend des contraints.
Je voudrais bien savoir avec quel outil du développe le module comme ça on sera sur la même longueur d'onde.
Cordialement
Si j'ai bien compris la Table Instance a pour But de spécifier les téléphones non affecter ?
A mon avis pas besoin d'une Table instance!rien n'empêche que les Tables Retour et Réparation elles même peuvent nous donner l'information qu'on veux puisque un téléphone qui existe dans l'un de ces Tables est d'office un téléphone en instance a condition qu'il n'ai qu'une seul et unique affectation.une requête fera l'affaire.
en ce qui concerne le cas ou un téléphone subit une 2éme affectation, je ne sais pas qu'elle est la procédure mais on principe une téléphone ne peut subir une second affectation que si il est déjà passer par la table Retour ou Réparation, mais la table comme elle est maintenant permettra de faire une second affectation puisque on a q'une seul clé Primaire IdAffectation et le champ Date fera indice pour différencier les affectations d'un même téléphone a condition bien sure que l'affectation n'est possible qu'une seul fois par jour.tous dépend des contraints.
Je voudrais bien savoir avec quel outil du développe le module comme ça on sera sur la même longueur d'onde.
Cordialement
pulls
Messages postés
136
Date d'inscription
mercredi 30 décembre 2009
Statut
Membre
Dernière intervention
13 septembre 2023
3
9 août 2013 à 14:15
9 août 2013 à 14:15
Salut Cher ami,
J'ai été malade et j'ai interrompu le travail depuis près d'une semaine.
En effet, vous avez raison par rapport à la table Instance, une simple requête pourra nous permettre de connaitre les téléphones non affectés, non expédiés, en reparation, ou au rébus ( qui ne peuvent plus être réparés).
voici enfin ce que j'ai défini comme table:
1er module déjà en exploitation
PRODUIT ( idProduit, libelle, idFournisseur#)
// il s'agit ici des consommables pour le téléphone comme encre, rouleau papier pour imprimante
MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit# ou idAccessoires# ou idMaterie# ou idSuppAcc#, expediteur, destinataire)
DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables,
2ème module à intégrer
ACCESSOIRE( idAccessoire, avec Support? ( oui ou non), libelle, idFournisseur#)
SUPPORT_ACCESSOIRE( idSuppAcc, libelle, idFournisseur#)
MATERIEL ( idMateriel, avec accessoire? ( oui ou non) , libelle, idFournisseur#)
// Nouveau: je viens d'ajouter ces 3 précédentes tables, par rapport aux nouvelles informations; en effet un téléphone pour fonctionner doit avoir un numéro ( Accessoires) et un numéro pour fonctionner doit avoir une puce ( SUPPORT_ACCESSOIRE) , une puce sur un numéro peut se griller et être remplacée par une autre puce de numéro de série différent, et un numéro avec sa puce peut passer d'un téléphone à un autre téléphone , exemple : si la puce d'un téléphone sur le terrain ( affecté) se grille, on peut prendre une puce sur le téléphone en réparation pour le secourir et ça peut rester définitif dans ce téléphone.
CODIFICATION( idCodification, dateCodification, idAgent#, idMouvement#, n° série)
// ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant.
ASSOC_ACCESSOIRE( idAssocAc, dateDebut, dateFin, idCodification# ( pour accessoire), idCodification# ( pour support))
// ici on associe un support ( puce) à un accessoire ( numéro téléphone)
ASSOC_MATERIEL ( idAssocMat, dateDebut, dateFin, idCodification#( pour materiel), idAssocAc#)
// ici on associe un accessoire ( numéro de téléphone ) avec son support ( puce) à un matériel ( téléphone)
VALIDATION ( idValidation, idAssocMat#,agent,responsable)
// ici on fait valider un téléphone complet ( avec accessoire) avant affectation ou Expédition
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur,
idValidation#)
EXPEDITION( idExpédition, datedepart, villeDepart, dateArrivée, villeArrivee,idValidation#, agentDepart,agentArrivee)
REPARATION( idReparation, idAffectation#, idExpédition#,dateReparation, technicien)
REBUS ( idRebus, idReparation#, prix vente, observation, dateRebus)
Voici mes préoccupations:
1- Je ne sais pas si ma logique est correcte et souple.
2- J'ai créé 4 tables pour les différents produits:
a) Table produit pour les consommables
b) Table matériel pour les téléphones
c) Table Accessoire pour les numéros téléphone
d) Table Support_Accessoire pour les puces de téléphone
Vous me direz que l'autre solution , était de creer , un seule table produit qui contiendra tout ça, avec un champ typeProduit pour consommable, materiel, accessoire et support _accessoire; mais vu la nature des champs des différentes tables , j'ai éclaté en 4 tables. L'une des conséquence de ma démarche , est que pour faire un mouvement de stock( voir table mouvement), je dois préciser avec des boutons radio, s'il s'agit d'un consommable, d'un materiel, d'un accessoire ou d'un support accessoire. Je ne sais pas si c'est optimisé d'éclater en plusieurs tables?
3- La table CODIFICATION contient : la codification du matériel ( téléphone), la codification des accessoires ( numéro tel) et la codification des supports accessoires ( puce téléphone). Est ce que c'est optimisé de mettre toutes les codification dans une même table? car je pouvais créer 3 table: codification_materie, codification_accessoire, codification_support_accessoire.
Quelle est la solution optimale?
Je vous remercie de votre précieuse aide
Cordialement.
J'ai été malade et j'ai interrompu le travail depuis près d'une semaine.
En effet, vous avez raison par rapport à la table Instance, une simple requête pourra nous permettre de connaitre les téléphones non affectés, non expédiés, en reparation, ou au rébus ( qui ne peuvent plus être réparés).
voici enfin ce que j'ai défini comme table:
1er module déjà en exploitation
PRODUIT ( idProduit, libelle, idFournisseur#)
// il s'agit ici des consommables pour le téléphone comme encre, rouleau papier pour imprimante
MOUVEMENT( idMouvement, date, typeMouvement ( entrée ou sortie), quantité, idville#, idProduit# ou idAccessoires# ou idMaterie# ou idSuppAcc#, expediteur, destinataire)
DISTRIBUTION( idDistribution, idProduit#, idVille#, date, vendeur, quantité) // il s'agit ici de la distribution des consommables,
2ème module à intégrer
ACCESSOIRE( idAccessoire, avec Support? ( oui ou non), libelle, idFournisseur#)
SUPPORT_ACCESSOIRE( idSuppAcc, libelle, idFournisseur#)
MATERIEL ( idMateriel, avec accessoire? ( oui ou non) , libelle, idFournisseur#)
// Nouveau: je viens d'ajouter ces 3 précédentes tables, par rapport aux nouvelles informations; en effet un téléphone pour fonctionner doit avoir un numéro ( Accessoires) et un numéro pour fonctionner doit avoir une puce ( SUPPORT_ACCESSOIRE) , une puce sur un numéro peut se griller et être remplacée par une autre puce de numéro de série différent, et un numéro avec sa puce peut passer d'un téléphone à un autre téléphone , exemple : si la puce d'un téléphone sur le terrain ( affecté) se grille, on peut prendre une puce sur le téléphone en réparation pour le secourir et ça peut rester définitif dans ce téléphone.
CODIFICATION( idCodification, dateCodification, idAgent#, idMouvement#, n° série)
// ici j'ai lié la table codification à la table mouvement, puisque en connaissant l'id d'un mouvement, on peut connaitre le produit correspondant.
ASSOC_ACCESSOIRE( idAssocAc, dateDebut, dateFin, idCodification# ( pour accessoire), idCodification# ( pour support))
// ici on associe un support ( puce) à un accessoire ( numéro téléphone)
ASSOC_MATERIEL ( idAssocMat, dateDebut, dateFin, idCodification#( pour materiel), idAssocAc#)
// ici on associe un accessoire ( numéro de téléphone ) avec son support ( puce) à un matériel ( téléphone)
VALIDATION ( idValidation, idAssocMat#,agent,responsable)
// ici on fait valider un téléphone complet ( avec accessoire) avant affectation ou Expédition
AFFECTATION( idAffectation, dateAffectation, dateFinAffectation, codeVendeur,
idValidation#)
EXPEDITION( idExpédition, datedepart, villeDepart, dateArrivée, villeArrivee,idValidation#, agentDepart,agentArrivee)
REPARATION( idReparation, idAffectation#, idExpédition#,dateReparation, technicien)
REBUS ( idRebus, idReparation#, prix vente, observation, dateRebus)
Voici mes préoccupations:
1- Je ne sais pas si ma logique est correcte et souple.
2- J'ai créé 4 tables pour les différents produits:
a) Table produit pour les consommables
b) Table matériel pour les téléphones
c) Table Accessoire pour les numéros téléphone
d) Table Support_Accessoire pour les puces de téléphone
Vous me direz que l'autre solution , était de creer , un seule table produit qui contiendra tout ça, avec un champ typeProduit pour consommable, materiel, accessoire et support _accessoire; mais vu la nature des champs des différentes tables , j'ai éclaté en 4 tables. L'une des conséquence de ma démarche , est que pour faire un mouvement de stock( voir table mouvement), je dois préciser avec des boutons radio, s'il s'agit d'un consommable, d'un materiel, d'un accessoire ou d'un support accessoire. Je ne sais pas si c'est optimisé d'éclater en plusieurs tables?
3- La table CODIFICATION contient : la codification du matériel ( téléphone), la codification des accessoires ( numéro tel) et la codification des supports accessoires ( puce téléphone). Est ce que c'est optimisé de mettre toutes les codification dans une même table? car je pouvais créer 3 table: codification_materie, codification_accessoire, codification_support_accessoire.
Quelle est la solution optimale?
Je vous remercie de votre précieuse aide
Cordialement.
