Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
-> 3 tables (cl=E9s primaires entre {}) :
Retours : {RefRetour} , RefFournisseur , RefAdresse
Fournisseurs : {RefFournisseur} , Nom
Adresses : {RefAdresse}, Rue , Ville
En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur}
et Retours.RefAdresse avec Adresses.{RefAdresse}
Quand je cr=E9er un nouveau "retour", je dois bien choisir un
fournisseur existant, mais je peux saisir une adresse qui ne concerne
pas ce fournisseur !
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
-> 3 tables (clés primaires entre {}) : Retours : {RefRetour} , RefFournisseur , RefAdresse Fournisseurs : {RefFournisseur} , Nom Adresses : {RefAdresse}, Rue , Ville
En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur} et Retours.RefAdresse avec Adresses.{RefAdresse}
Quand je créer un nouveau "retour", je dois bien choisir un fournisseur existant, mais je peux saisir une adresse qui ne concerne pas ce fournisseur !
Une idée ?
Bonsoir,
A priori, plutôt faire :
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur} , Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
db
izsobad1
Merci de ta réponse. Mais peu importe l'ordre et les données, je cherche la technique pour réaliser ça ?
On 12 nov, 18:35, db wrote:
a écrit :
> Bonjour,
> Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque > "Fournisseur" pouvant avoir plusieurs "Adresses"
> -> 3 tables (clés primaires entre {}) : > Retours : {RefRetour} , RefFournisseur , RefAdresse > Fournisseurs : {RefFournisseur} , Nom > Adresses : {RefAdresse}, Rue , Ville
> En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur} > et Retours.RefAdresse avec Adresses.{RefAdresse}
> Quand je créer un nouveau "retour", je dois bien choisir un > fournisseur existant, mais je peux saisir une adresse qui ne concerne > pas ce fournisseur !
> Une idée ?
Bonsoir,
A priori, plutôt faire :
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur} , Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
db
Merci de ta réponse.
Mais peu importe l'ordre et les données, je cherche la technique pour
réaliser ça ?
On 12 nov, 18:35, db <blue_moon_fr@_hotmail.com> wrote:
izsob...@googlemail.com a écrit :
> Bonjour,
> Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
> "Fournisseur" pouvant avoir plusieurs "Adresses"
> -> 3 tables (clés primaires entre {}) :
> Retours : {RefRetour} , RefFournisseur , RefAdresse
> Fournisseurs : {RefFournisseur} , Nom
> Adresses : {RefAdresse}, Rue , Ville
> En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur}
> et Retours.RefAdresse avec Adresses.{RefAdresse}
> Quand je créer un nouveau "retour", je dois bien choisir un
> fournisseur existant, mais je peux saisir une adresse qui ne concerne
> pas ce fournisseur !
> Une idée ?
Bonsoir,
A priori, plutôt faire :
Retours : {RefRetour} , RefAdresse
Fournisseurs : {RefFournisseur} , Nom
Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
Merci de ta réponse. Mais peu importe l'ordre et les données, je cherche la technique pour réaliser ça ?
On 12 nov, 18:35, db wrote:
a écrit :
> Bonjour,
> Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque > "Fournisseur" pouvant avoir plusieurs "Adresses"
> -> 3 tables (clés primaires entre {}) : > Retours : {RefRetour} , RefFournisseur , RefAdresse > Fournisseurs : {RefFournisseur} , Nom > Adresses : {RefAdresse}, Rue , Ville
> En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur} > et Retours.RefAdresse avec Adresses.{RefAdresse}
> Quand je créer un nouveau "retour", je dois bien choisir un > fournisseur existant, mais je peux saisir une adresse qui ne concerne > pas ce fournisseur !
> Une idée ?
Bonsoir,
A priori, plutôt faire :
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur} , Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
db
db
a écrit :
Merci de ta réponse. Mais peu importe l'ordre et les données, je cherche la technique pour réaliser ça ?
Si vous ne voulez pas toucher à vos données, je vous souhaite bon courage...
db
izsobad1@googlemail.com a écrit :
Merci de ta réponse.
Mais peu importe l'ordre et les données, je cherche la technique pour
réaliser ça ?
Si vous ne voulez pas toucher à vos données, je vous souhaite bon courage...
Retours : {RefRetour} , RefFournisseur Fournisseurs : {RefFournisseur}, RefAdresse, Nom Adresses : {RefAdresse}, Rue , Ville
Cdt, Blaise ---- ---- ----
a écrit dans le message de news:
Bonjour,
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
-> 3 tables (clés primaires entre {}) :
En liant Retours.RefFournisseur avec Fournisseur.{RefFournisseur} et Retours.RefAdresse avec Adresses.{RefAdresse}
Quand je créer un nouveau "retour", je dois bien choisir un fournisseur existant, mais je peux saisir une adresse qui ne concerne pas ce fournisseur !
Une idée ?
db
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Retours : {RefRetour} , RefFournisseur Fournisseurs : {RefFournisseur}, RefAdresse, Nom Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur}, Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une liste déroulante des adresses réactualiqée après le choix d'un fournisseur (et réciproquement)
db
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Retours : {RefRetour} , RefFournisseur
Fournisseurs : {RefFournisseur}, RefAdresse, Nom
Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
<izsobad1@googlemail.com> a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas
qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse
Fournisseurs : {RefFournisseur}, Nom
Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une
liste déroulante des adresses réactualiqée après le choix d'un
fournisseur (et réciproquement)
Retours : {RefRetour} , RefFournisseur Fournisseurs : {RefFournisseur}, RefAdresse, Nom Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur}, Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une liste déroulante des adresses réactualiqée après le choix d'un fournisseur (et réciproquement)
db
Blaise Cacramp
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news:
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Retours : {RefRetour} , RefFournisseur Fournisseurs : {RefFournisseur}, RefAdresse, Nom Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur}, Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une liste déroulante des adresses réactualiqée après le choix d'un fournisseur (et réciproquement)
db
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou
+sieurs adresses, mais les fournisseurs.
Cela me semble bizarre, mais je m'en tient à la formulation originale :
«
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
»
Dont acte.
Cdt, Blaise
---- ---- ----
"db" <blue_moon_fr@_hotmail.com> a écrit dans le message de news:
upE2aSIZKHA.196@TK2MSFTNGP05.phx.gbl...
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Retours : {RefRetour} , RefFournisseur
Fournisseurs : {RefFournisseur}, RefAdresse, Nom
Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
<izsobad1@googlemail.com> a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas
qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse
Fournisseurs : {RefFournisseur}, Nom
Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même
adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une
liste déroulante des adresses réactualiqée après le choix d'un fournisseur
(et réciproquement)
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news:
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Retours : {RefRetour} , RefFournisseur Fournisseurs : {RefFournisseur}, RefAdresse, Nom Adresses : {RefAdresse}, Rue , Ville
Mais, mon cher Blaise,
a écrit dans le message de news:
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses"
Si chaque Fournisseur peut avoir plusieurs adresses, ne pensez-vous pas qu'il serait préférable d'avoir
Retours : {RefRetour} , RefAdresse Fournisseurs : {RefFournisseur}, Nom Adresses : {RefAdresse}, RefFournisseur,Rue , Ville
si on suppose que plusieurs Fournisseurs n'habitent pas à la même adresse.
Non ?
Et, pour le mode de saisie, une liste déroulante des fournisseurs et une liste déroulante des adresses réactualiqée après le choix d'un fournisseur (et réciproquement)
db
db
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Je ne comprends pas votre réponse.
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou
+sieurs adresses, mais les fournisseurs.
Cela me semble bizarre, mais je m'en tient à la formulation originale :
«
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
»
Dont acte.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Je ne comprends pas votre réponse.
Blaise Cacramp
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news: %
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Je ne comprends pas votre réponse.
Selon : Bonjour ou bonsoir
1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce
jeu !
vous pouvez me contacter sur mon mail .
Cdt, Blaise
---- ---- ----
"db" <blue_moon_fr@_hotmail.com> a écrit dans le message de news:
%23KLDxHJZKHA.2188@TK2MSFTNGP04.phx.gbl...
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une
ou +sieurs adresses, mais les fournisseurs.
Cela me semble bizarre, mais je m'en tient à la formulation originale :
«
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
»
Dont acte.
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news: %
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
Non.
Si je m'en tient à la formulation, ce ne sont pas les retours qui ont une ou +sieurs adresses, mais les fournisseurs. Cela me semble bizarre, mais je m'en tient à la formulation originale : « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" » Dont acte.
Je ne comprends pas votre réponse.
db
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses, alors l'adresse ne pouvait pas être un attribut de la table fournisseurs (qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que la table adresses pouvait avoir comme attribut le fournisseur.
Mais, si cette discussion (qui n'est pas un troll) vous gêne, pas de problème pour arrêter.
Bonne soirée.
db
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce
jeu !
vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais
juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses,
alors l'adresse ne pouvait pas être un attribut de la table fournisseurs
(qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que
la table adresses pouvait avoir comme attribut le fournisseur.
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses, alors l'adresse ne pouvait pas être un attribut de la table fournisseurs (qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que la table adresses pouvait avoir comme attribut le fournisseur.
Mais, si cette discussion (qui n'est pas un troll) vous gêne, pas de problème pour arrêter.
Bonne soirée.
db
Blaise Cacramp
Selon : Bonjour ou bonsoir
Mes excuses. Fin de semaine ;-)
Il est vrai que je trouve curieux qu'un fournisseur possède plusieurs adresses, mais je répond à la question posée « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" »
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news:
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses, alors l'adresse ne pouvait pas être un attribut de la table fournisseurs (qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que la table adresses pouvait avoir comme attribut le fournisseur.
Mais, si cette discussion (qui n'est pas un troll) vous gêne, pas de problème pour arrêter.
Bonne soirée.
db
Selon : Bonjour ou bonsoir
Mes excuses. Fin de semaine ;-)
Il est vrai que je trouve curieux qu'un fournisseur possède plusieurs
adresses, mais je répond à la question posée
«
Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque
"Fournisseur" pouvant avoir plusieurs "Adresses"
»
Cdt, Blaise
---- ---- ----
"db" <blue_moon_fr@_hotmail.com> a écrit dans le message de news:
OfKkRvJZKHA.4148@TK2MSFTNGP04.phx.gbl...
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir
1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter
ce jeu !
vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais
juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses,
alors l'adresse ne pouvait pas être un attribut de la table fournisseurs
(qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que la
table adresses pouvait avoir comme attribut le fournisseur.
Il est vrai que je trouve curieux qu'un fournisseur possède plusieurs adresses, mais je répond à la question posée « Soit une table "Retours" qui contient plusieurs "Fournisseurs", chaque "Fournisseur" pouvant avoir plusieurs "Adresses" »
Cdt, Blaise ---- ---- ----
"db" a écrit dans le message de news:
Blaise Cacramp a écrit :
Selon : Bonjour ou bonsoir 1 retour => +sieurs fournisseurs => +sieurs adresses
Mais il me semble que vous me provoquez (= troll). Il faudrait arrêter ce jeu ! vous pouvez me contacter sur mon mail .
Désolé si j'ai semblé vous provoquer, ce n'est pas le cas. Je voulais juste indiquer que, si un fournisseur pouvait avoir plusieurs adresses, alors l'adresse ne pouvait pas être un attribut de la table fournisseurs (qui, du coup, ne pouvait avoir qu'une adresse). Mais, à l'inverse, que la table adresses pouvait avoir comme attribut le fournisseur.
