Un fichier CLIENT (banal)
Un fichier SERVICES (un client pouvant est subdivisé en services)
Identifiant = clef composée code_client + code_service
Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères:
Code_client et éventuellement code_service
+ clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romuald.besset
louis a écrit :
Bonjour,
soit
Un fichier CLIENT (banal) Un fichier SERVICES (un client pouvant est subdivisé en services) Identifiant = clef composée code_client + code_service Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères: Code_client et éventuellement code_service + clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Merci
Louis
Bonjour Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service // dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
++ R&B de www.WDForge.org
louis a écrit :
Bonjour,
soit
Un fichier CLIENT (banal)
Un fichier SERVICES (un client pouvant est subdivisé en services)
Identifiant = clef composée code_client + code_service
Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères:
Code_client et éventuellement code_service
+ clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Merci
Louis
Bonjour
Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
Dans lignes de ventes il faut respectivement code_client et
code_service, une clé composée propre à ce fichier peut ensuite servir
pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez
vous permettre :
Ventes_lignes 0,1 --(code_client)--> 0,n client
ET
Ventes_lignes 0,1 --(code_service)--> 0,n service
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de
ventes_lignes.code_client
Un fichier CLIENT (banal) Un fichier SERVICES (un client pouvant est subdivisé en services) Identifiant = clef composée code_client + code_service Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères: Code_client et éventuellement code_service + clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Merci
Louis
Bonjour Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service // dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
++ R&B de www.WDForge.org
louis
"Romuald.besset" a écrit dans le message de news: <ctr0gm$ooa$...
louis a écrit :
> Bonjour, > > soit > > Un fichier CLIENT (banal) > Un fichier SERVICES (un client pouvant est subdivisé en services) > Identifiant = clef composée code_client + code_service > Un champ texte : nom_du_service > > > Un fichier lignes de vente avec les clef étrangères: > Code_client et éventuellement code_service > + clef composée code_client + code_service > > > Comment doit on gérer cela? > > L'éditeur d'analyse refuse d'utiliser une clef composée comme clef > étrangère > > Merci > > Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE un code_service en filtrant le fichier services sur mon code_client : une clef composée bien que calculée pourrait servir de clé étrangère pour pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et à une "sous famille" ...
Encore Merci
Louis
"Romuald.besset" <info@wdforge.org> a écrit dans le message de news:
<ctr0gm$ooa$1@s1.news.oleane.net>...
louis a écrit :
> Bonjour,
>
> soit
>
> Un fichier CLIENT (banal)
> Un fichier SERVICES (un client pouvant est subdivisé en services)
> Identifiant = clef composée code_client + code_service
> Un champ texte : nom_du_service
>
>
> Un fichier lignes de vente avec les clef étrangères:
> Code_client et éventuellement code_service
> + clef composée code_client + code_service
>
>
> Comment doit on gérer cela?
>
> L'éditeur d'analyse refuse d'utiliser une clef composée comme clef
> étrangère
>
> Merci
>
> Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela
s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE
un code_service en filtrant le fichier services sur mon code_client : une
clef composée bien que calculée pourrait servir de clé étrangère pour
pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et
code_service, une clé composée propre à ce fichier peut ensuite servir
pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous
pouvez
vous permettre :
Ventes_lignes 0,1 --(code_client)--> 0,n client
ET
Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de
ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant
pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service
soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et
à une "sous famille" ...
"Romuald.besset" a écrit dans le message de news: <ctr0gm$ooa$...
louis a écrit :
> Bonjour, > > soit > > Un fichier CLIENT (banal) > Un fichier SERVICES (un client pouvant est subdivisé en services) > Identifiant = clef composée code_client + code_service > Un champ texte : nom_du_service > > > Un fichier lignes de vente avec les clef étrangères: > Code_client et éventuellement code_service > + clef composée code_client + code_service > > > Comment doit on gérer cela? > > L'éditeur d'analyse refuse d'utiliser une clef composée comme clef > étrangère > > Merci > > Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE un code_service en filtrant le fichier services sur mon code_client : une clef composée bien que calculée pourrait servir de clé étrangère pour pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et à une "sous famille" ...
Encore Merci
Louis
digging
louis avait soumis l'idée :
"Romuald.besset" a écrit dans le message de news: <ctr0gm$ooa$...
louis a écrit :
Bonjour,
soit
Un fichier CLIENT (banal) Un fichier SERVICES (un client pouvant est subdivisé en services) Identifiant = clef composée code_client + code_service Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères: Code_client et éventuellement code_service + clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Merci
Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE un code_service en filtrant le fichier services sur mon code_client : une clef composée bien que calculée pourrait servir de clé étrangère pour pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et à une "sous famille" ...
Encore Merci
Louis
C'est une erreur de conception tout simplement. Chaque table doit avoir sa propre clé ! mets en une auto si tu veux. Dans les liaisons, c'est la clé propre à la table qui est propagée et non la clé composée. De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas être porteur d'informations, c'est à dire pas de clé fabriquée en additionnant le 3ème caractère plus un nombre, etc. Il est nécessaire de suivre toutes les règles de modélisation pour clarifier ce genre de situation. Je sais on s'en fout de CODD, Morejon et les autres. Voilà, voilà. digging
-- - concepteur ensemblier -
louis avait soumis l'idée :
"Romuald.besset" <info@wdforge.org> a écrit dans le message de news:
<ctr0gm$ooa$1@s1.news.oleane.net>...
louis a écrit :
Bonjour,
soit
Un fichier CLIENT (banal)
Un fichier SERVICES (un client pouvant est subdivisé en services)
Identifiant = clef composée code_client + code_service
Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères:
Code_client et éventuellement code_service
+ clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef
étrangère
Merci
Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela
s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE
un code_service en filtrant le fichier services sur mon code_client : une
clef composée bien que calculée pourrait servir de clé étrangère pour
pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et
code_service, une clé composée propre à ce fichier peut ensuite servir
pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous
pouvez
vous permettre :
Ventes_lignes 0,1 --(code_client)--> 0,n client
ET
Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de
ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant
pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service
soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et
à une "sous famille" ...
Encore Merci
Louis
C'est une erreur de conception tout simplement.
Chaque table doit avoir sa propre clé ! mets en une auto si tu veux.
Dans les liaisons, c'est la clé propre à la table qui est propagée et
non la clé composée.
De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas
être porteur d'informations, c'est à dire pas de clé fabriquée en
additionnant le 3ème caractère plus un nombre, etc.
Il est nécessaire de suivre toutes les règles de modélisation pour
clarifier ce genre de situation. Je sais on s'en fout de CODD, Morejon
et les autres.
Voilà, voilà.
digging
"Romuald.besset" a écrit dans le message de news: <ctr0gm$ooa$...
louis a écrit :
Bonjour,
soit
Un fichier CLIENT (banal) Un fichier SERVICES (un client pouvant est subdivisé en services) Identifiant = clef composée code_client + code_service Un champ texte : nom_du_service
Un fichier lignes de vente avec les clef étrangères: Code_client et éventuellement code_service + clef composée code_client + code_service
Comment doit on gérer cela?
L'éditeur d'analyse refuse d'utiliser une clef composée comme clef étrangère
Merci
Louis
Tout d'abord MERCI
Pour l'éditeur d'analyse, les clés composée étant calculée, cela s'explique.
... Peut être mais je ne vois pas pourquoi
dans mon fichier ventes_lignes , je saisi un code_client, je SELECTIONNE un code_service en filtrant le fichier services sur mon code_client : une clef composée bien que calculée pourrait servir de clé étrangère pour pointer sur le service approprié !! Non ?
Dans lignes de ventes il faut respectivement code_client et code_service, une clé composée propre à ce fichier peut ensuite servir pour les parcours.
coté relation, si vous avez Client 0,n <- 0,1 Service alors vous pouvez vous permettre : Ventes_lignes 0,1 --(code_client)--> 0,n client ET Ventes_lignes 0,1 --(code_service)--> 0,n service
Non...
// dans ce cas, il faut utiliser service.codeclient pour l'écriture de ventes_lignes.code_client
un service étant toujours rattaché à un client !
Non car un code_service n'est pas une clef unique en soit : le service ayant pour code "compta" par exemple n'est pas unique
La clef d'un service chez un client est bien code_client+code_service
Je ne vois comme solution que de construire la clef code_client_code_service soi même avant enregistrement !!!
Étonnant non !
J'ai un problème similaire avec des "ARTICLE" appartenant à une "famille" et à une "sous famille" ...
Encore Merci
Louis
C'est une erreur de conception tout simplement. Chaque table doit avoir sa propre clé ! mets en une auto si tu veux. Dans les liaisons, c'est la clé propre à la table qui est propagée et non la clé composée. De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas être porteur d'informations, c'est à dire pas de clé fabriquée en additionnant le 3ème caractère plus un nombre, etc. Il est nécessaire de suivre toutes les règles de modélisation pour clarifier ce genre de situation. Je sais on s'en fout de CODD, Morejon et les autres. Voilà, voilà. digging
-- - concepteur ensemblier -
louis
"digging" a écrit dans le message de news:
louis avait soumis l'idée : > > "Romuald.besset" a écrit dans le message de news: > <ctr0gm$ooa$... >> louis a écrit : >> >>> Bonjour, >>> >>> soit >>> >>> Un fichier CLIENT (banal) >>> Un fichier SERVICES (un client pouvant est subdivisé en services) >>> Identifiant = clef composée code_client + code_service >>> Un champ texte : nom_du_service >>> >>> >>> Un fichier lignes de vente avec les clef étrangères: >>> Code_client et éventuellement code_service >>> + clef composée code_client + code_service >>> >>> >>> Comment doit on gérer cela? >>> >>> L'éditeur d'analyse refuse d'utiliser une clef composée comme clef >>> étrangère >>> >>> Merci >>> >>> Louis > >
Tout d'abord MERCI
C'est une erreur de conception tout simplement.
je veux bien le croire mais je veux comprendre
Chaque table doit avoir sa propre clé !
Je suis d'accord
mets en une auto si tu veux.
Je suis moins d'accord ... une clé auto rends les données trop liées à la base de donnée en question Un N° chrono : oui un identifiant auto plutot non
Dans les liaisons, c'est la clé propre à la table qui est propagée et non la clé composée.
Là est mon intérrogation ...
De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas être porteur d'informations,
Ne peut-il ( ne doit-il ) pas être (en partie ) mnémonique ? : code_client , code service ?
c'est à dire pas de clé fabriquée en additionnant le 3ème caractère plus un nombre, etc.
!!!
L'identifiant d'un service d'un client n'est il pas la "concaténation" des identifiants client et service ?
si oui, comme une ligne de vente comprend déja ces deux identifiants, il me semblait logique que la liaison vers les propriétés du service du client en question en découle sans être obligé d'y ajouter l'identifiant de CLIENT_SERVICE (impression de double emploi.)...
Il est nécessaire de suivre toutes les règles de modélisation pour clarifier ce genre de situation.
C'est l'objet de ma demande
Je sais on s'en fout de CODD, Morejon et les autres.
Pourquoi cette petite phrase ??
Voilà, voilà. digging
-- - concepteur ensemblier -
"digging" <digging@nospam.fr> a écrit dans le message de
news:mn.25947d520353d09d.20812@nospam.fr...
louis avait soumis l'idée :
>
> "Romuald.besset" <info@wdforge.org> a écrit dans le message de news:
> <ctr0gm$ooa$1@s1.news.oleane.net>...
>> louis a écrit :
>>
>>> Bonjour,
>>>
>>> soit
>>>
>>> Un fichier CLIENT (banal)
>>> Un fichier SERVICES (un client pouvant est subdivisé en services)
>>> Identifiant = clef composée code_client + code_service
>>> Un champ texte : nom_du_service
>>>
>>>
>>> Un fichier lignes de vente avec les clef étrangères:
>>> Code_client et éventuellement code_service
>>> + clef composée code_client + code_service
>>>
>>>
>>> Comment doit on gérer cela?
>>>
>>> L'éditeur d'analyse refuse d'utiliser une clef composée comme clef
>>> étrangère
>>>
>>> Merci
>>>
>>> Louis
>
>
Tout d'abord MERCI
C'est une erreur de conception tout simplement.
je veux bien le croire mais je veux comprendre
Chaque table doit avoir sa propre clé !
Je suis d'accord
mets en une auto si tu veux.
Je suis moins d'accord ... une clé auto rends les données trop liées à la
base de donnée en question
Un N° chrono : oui un identifiant auto plutot non
Dans les liaisons, c'est la clé propre à la table qui est propagée et
non la clé composée.
Là est mon intérrogation ...
De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas
être porteur d'informations,
Ne peut-il ( ne doit-il ) pas être (en partie ) mnémonique ? : code_client
, code service ?
c'est à dire pas de clé fabriquée en
additionnant le 3ème caractère plus un nombre, etc.
!!!
L'identifiant d'un service d'un client n'est il pas la "concaténation" des
identifiants client et service ?
si oui, comme une ligne de vente comprend déja ces deux identifiants, il me
semblait logique que la liaison vers les propriétés du service du client en
question en découle sans être obligé d'y ajouter l'identifiant de
CLIENT_SERVICE (impression de double emploi.)...
Il est nécessaire de suivre toutes les règles de modélisation pour
clarifier ce genre de situation.
C'est l'objet de ma demande
Je sais on s'en fout de CODD, Morejon et les autres.
louis avait soumis l'idée : > > "Romuald.besset" a écrit dans le message de news: > <ctr0gm$ooa$... >> louis a écrit : >> >>> Bonjour, >>> >>> soit >>> >>> Un fichier CLIENT (banal) >>> Un fichier SERVICES (un client pouvant est subdivisé en services) >>> Identifiant = clef composée code_client + code_service >>> Un champ texte : nom_du_service >>> >>> >>> Un fichier lignes de vente avec les clef étrangères: >>> Code_client et éventuellement code_service >>> + clef composée code_client + code_service >>> >>> >>> Comment doit on gérer cela? >>> >>> L'éditeur d'analyse refuse d'utiliser une clef composée comme clef >>> étrangère >>> >>> Merci >>> >>> Louis > >
Tout d'abord MERCI
C'est une erreur de conception tout simplement.
je veux bien le croire mais je veux comprendre
Chaque table doit avoir sa propre clé !
Je suis d'accord
mets en une auto si tu veux.
Je suis moins d'accord ... une clé auto rends les données trop liées à la base de donnée en question Un N° chrono : oui un identifiant auto plutot non
Dans les liaisons, c'est la clé propre à la table qui est propagée et non la clé composée.
Là est mon intérrogation ...
De plus, l'identifiant ne doit avoir AUCUNE signification et ne pas être porteur d'informations,
Ne peut-il ( ne doit-il ) pas être (en partie ) mnémonique ? : code_client , code service ?
c'est à dire pas de clé fabriquée en additionnant le 3ème caractère plus un nombre, etc.
!!!
L'identifiant d'un service d'un client n'est il pas la "concaténation" des identifiants client et service ?
si oui, comme une ligne de vente comprend déja ces deux identifiants, il me semblait logique que la liaison vers les propriétés du service du client en question en découle sans être obligé d'y ajouter l'identifiant de CLIENT_SERVICE (impression de double emploi.)...
Il est nécessaire de suivre toutes les règles de modélisation pour clarifier ce genre de situation.
C'est l'objet de ma demande
Je sais on s'en fout de CODD, Morejon et les autres.
