A voir également:
- Choix conception bdd
- Liste déroulante de choix excel - Guide
- Votre envoi est réexpédié à la demande du destinataire vers l'adresse de son choix. - Forum Réseaux sociaux
- Choix mini pc - Accueil - Guide ordinateurs
- Idée de conception powerpoint n'apparait pas - Forum Powerpoint
- Choix imprimante jet d encre - Guide
4 réponses
giheller
Messages postés
1875
Date d'inscription
dimanche 14 juin 2009
Statut
Membre
Dernière intervention
3 février 2024
142
5 juil. 2009 à 11:40
5 juil. 2009 à 11:40
bonjour,
je serais tenté de répondre qu'il faut plusieurs tables afin qu'un client ne soit pas lié à un fournisseur.
un clinet peut avoir plusieur fournisseur, ainsi la commande d'un client ferait référence à un numéro de fournisseur.
mais ai-je bien compros votre soucis c'est un autre problème!
je serais tenté de répondre qu'il faut plusieurs tables afin qu'un client ne soit pas lié à un fournisseur.
un clinet peut avoir plusieur fournisseur, ainsi la commande d'un client ferait référence à un numéro de fournisseur.
mais ai-je bien compros votre soucis c'est un autre problème!
moderno31
Messages postés
870
Date d'inscription
mardi 23 juin 2009
Statut
Membre
Dernière intervention
8 août 2012
92
5 juil. 2009 à 20:04
5 juil. 2009 à 20:04
Hello,
Ma réponse s'ajoute à celle de "giheller", tant que tu trouves des informations qui se répètent il fait créer des entités pour rendre le plus performant son système.
Pour bien te conseiller, peux-tu me dire chaque champs de chaque table dont identifiants et clés étrangères. Là comme ça je ne visualise pas bie ton schéma (surtout les différents champs)
Ma réponse s'ajoute à celle de "giheller", tant que tu trouves des informations qui se répètent il fait créer des entités pour rendre le plus performant son système.
Pour bien te conseiller, peux-tu me dire chaque champs de chaque table dont identifiants et clés étrangères. Là comme ça je ne visualise pas bie ton schéma (surtout les différents champs)
merci
au fait, le client et le fournisseur ont des champs en commun: nom, adresse, tél
des champs concernent uniquement le client exemple : âge
des champs ne concernent que le fournisseur exemple : activité
ce qui apparait logique est une table "utilisateur" avec les champs en commun, ensuite deux tables client et fournisseur.
deuxième piste est une seule table avec une clé pour pointer vers les infos client ou fournisseur
les requêtes ne mettent pas moins de temps sur une seule table que sur 3 tables ce qui plaide pour cette deuxième piste ?
au fait, le client et le fournisseur ont des champs en commun: nom, adresse, tél
des champs concernent uniquement le client exemple : âge
des champs ne concernent que le fournisseur exemple : activité
ce qui apparait logique est une table "utilisateur" avec les champs en commun, ensuite deux tables client et fournisseur.
deuxième piste est une seule table avec une clé pour pointer vers les infos client ou fournisseur
les requêtes ne mettent pas moins de temps sur une seule table que sur 3 tables ce qui plaide pour cette deuxième piste ?
Salut
Pour ma part, les tables client et fournisseur ne font qu'une. C'est pas moi qui l'ai pondu mais c'est basé sur l'expérience: ma société a plus d'une fois vendue une prestation à une boîte qui a l'habitude de nous vendre du matos ; les sociétés se dépannent aussi entre elles : qqes fois, nous achetons tel produit chez X, d'autres fois c'est lui qui l'achète chez nous.
Vu que nous n'avons pas énormément de clients + fournisseurs, le fait qu'ils partagent la même table n'impacte pas les perf du système... mais si nous étions comme La redoute(r) on y repenserait à deux fois. Mais si tu n'as ni énormément de clients ni énormément de fournisseurs, tu peux alors rester dans la simplicité d'une seule table
Pour ma part, les tables client et fournisseur ne font qu'une. C'est pas moi qui l'ai pondu mais c'est basé sur l'expérience: ma société a plus d'une fois vendue une prestation à une boîte qui a l'habitude de nous vendre du matos ; les sociétés se dépannent aussi entre elles : qqes fois, nous achetons tel produit chez X, d'autres fois c'est lui qui l'achète chez nous.
Vu que nous n'avons pas énormément de clients + fournisseurs, le fait qu'ils partagent la même table n'impacte pas les perf du système... mais si nous étions comme La redoute(r) on y repenserait à deux fois. Mais si tu n'as ni énormément de clients ni énormément de fournisseurs, tu peux alors rester dans la simplicité d'une seule table