IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

Requête pour association réflexive


Sujet :

Langage SQL

  1. #21
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Ça c'est parfaitement assimilé depuis des lustres. Mais donc, pour les CHAR et compagnie, c'est l'intérêt de pouvoir utiliser soit l'un soit l'autre que je n'ai jamais réussi à assimiler. Quand un employé consulte le formulaire d'une personne et qu'il voit que dans le nom de jeune fille (je sais, ça n'existe plus) il n'y a rien d'inscrit, il n'a aucun moyen de savoir (et en tant qu'employé, ça lui importe peu) si c'est vide ou si c'est NULL. Tout ce que j'y vois comme différence, c'est de la complication que je juge inutile. Si la table a été remplie par un script effectué par un tiers et sur lequel on n'a eu aucun contrôle, ça implique de compliquer les requêtes avec des IS NULL OR = '' pour créer des filtrages.

    NULL est une absence de valeur. Ok. Tu ajoutes que c'est parce que la valeur est inconnue. Ok aussi. Mais si la "cellule" est vide à la place de NULL, ça veut dire également qu'elle est inconnue, non ? Mais même "inconnue" amène des questions : inconnue parce qu'on ne la connaît pas, parce que l'information n'a pas encore été donnée ou inconnue parce qu'elle ne peut exister dans un cas précis, par exemple le nom de jeune fille pour un homme ?

    Tu parles de la norme bancaire EMV où une valeur vide est valide pour certaines colonnes. Dans la structure de la table, ces colonnes ont une valeur par défaut paramétrée comme vide ou NULL ?

  2. #22
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 583
    Billets dans le blog
    10
    Par défaut
    Le stockage dans la base de données est une chose, la facilité d'utilisation pour l'utilisateur en est une autre
    Pour le nom marital, vide signifie qu'il n'y a pas de nom marital, on a l'information, alors que "null" signifie qu'il n'est pas connu, peut-être y en a-t-il un.
    Mais pour l'utilisateur final, on peut restituer deux valeurs distinctes à l'écran ou sur les états, par exemple "néant" en italique quand la valeur est vide et "inconnu" en italique également quand la colonne est marquée "null". En italique ou avec tout autre typographie distinctive pour différencier les cas rares de personnes dont le nom marital serait "néant" ou "inconnu" ... ça doit pas se trouver tous les jours

  3. #23
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Pour le nom marital, vide signifie qu'il n'y a pas de nom marital, on a l'information, alors que "null" signifie qu'il n'est pas connu, peut-être y en a-t-il un.
    Ça n'a pas de sens et ça me dépasse. Lorsqu'on saisit les coordonnées d'une nouvelle personne dans un formulaire (par exemple, à partir des infos qu'on a sur un document papier) où à la création d'une nouvelle ligne rien n'est encore rempli, soit on a l'information et on saisit la valeur, soit on ne l'a pas et la cellule reste NULL ; qu'il n'y ait pas de nom marital ou qu'il ne soit pas connu ne change rien à la manipulation. On ne peut pas saisir 2 guillemets simples pour transformer le NULL en vide.

  4. #24
    Expert confirmé
    Homme Profil pro
    Responsable Données
    Inscrit en
    Janvier 2009
    Messages
    5 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : Janvier 2009
    Messages : 5 392
    Par défaut
    Quelle est la couleur des vitres latérales de ma voiture:
    1. Bleu
    2. Vert
    3. Acune
    4. Aucune idée

    Dans l'avant dernier cas la valeur est vide (pas de couleur), et dans le dernier cas il n'y a pas de valeur => null.
    C'est la différence entre "on sait qu'il n'y a rien" et "on ne sait pas ce qu'il y a".

    tatayo

  5. #25
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 583
    Billets dans le blog
    10
    Par défaut
    Citation Envoyé par Nerva Voir le message
    Ça n'a pas de sens et ça me dépasse. Lorsqu'on saisit les coordonnées d'une nouvelle personne dans un formulaire (par exemple, à partir des infos qu'on a sur un document papier) où à la création d'une nouvelle ligne rien n'est encore rempli, soit on a l'information et on saisit la valeur, soit on ne l'a pas et la cellule reste NULL ; qu'il n'y ait pas de nom marital ou qu'il ne soit pas connu ne change rien à la manipulation. On ne peut pas saisir 2 guillemets simples pour transformer le NULL en vide.
    Dans certains cas en effet il est difficile de trancher entre l'un et l'autre, mais ce n'est pas toujours vrai, et il important de pouvoir distinguer le manque d'information d'une information validant que la donnée est absente.

  6. #26
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Vos réponses sont parfaitement cohérentes, mais que l'on connaisse ou non l'information, qu'elle soit applicable ou pas, comment différencie t'on, à la saisie (ou plutôt à la non-saisie), un vide d'un NULL ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    IND_DATE_DEBUT DATE NOT NULL,
    IND_DATE_FIN DATE
    Pour la première colonne, la date de début est obligatoire.
    Pour la seconde colonne, cette date ne sera indiquée que lorsque le partenariat aura pris fin... et il prendra obligatoirement fin, tôt ou tard. À la création d'une ligne, la "valeur" de cette colonne est un marqueur NULL. Et elle est NULL, non pas parce que l'information n'existe tout simplement pas mais parce que elle n'existe pas encore à l'instant de la création de la ligne. Donc, si je suis votre raisonnement, sachant que tôt ou tard, une date sera saisie, elle devrait être paramétrée comme vide et non pas comme NULL.

    D'où cette question : mis à part en exécutant un script INSERT INTO du genre ('2024-04-01', '') pour les colonnes qui contiendront obligatoirement une information, comment paramètre-t-on une valeur par défaut vide à la place de NULL dans un script de création de table ?

    Et avec le nom de jeune fille :

    - Pour un homme, il ne sera jamais rempli : c'est donc un NULL.
    - Pour une femme, il sera peut-être rempli un jour : c'est donc un vide.

    Là encore, dans la table, il n'y a qu'une seule colonne pour ça ; par défaut, ça ne peut pas être en même temps vide et NULL.

    -----

    @escartefigue. Je reviens au sujet initial. Dans la dernière structure que tu as présentée, avec type et sous-types, la date de fin n'est pas indiquée. Elle est pourtant obligatoire pour différencier les partenariats en cours et terminés et pouvoir appliquer les règles de gestion, que je rappelle de manière plus complète :

    1) 1 interne peut avoir 0 ou plusieurs externes. Mais...
    2) 1 interne ne peut avoir qu'1 externe à la fois, dans une période définie entre une date de début et une date de fin.
    3) 1 interne peut avoir plusieurs fois le même externe tout en respectant la règle 2.
    4) 1 externe peut avoir plusieurs externes simultanément.

  7. #27
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 583
    Billets dans le blog
    10
    Par défaut
    Citation Envoyé par Nerva Voir le message
    Pour la seconde colonne, cette date ne sera indiquée que lorsque le partenariat aura pris fin... et il prendra obligatoirement fin, tôt ou tard. À la création d'une ligne, la "valeur" de cette colonne est un marqueur NULL. Et elle est NULL, non pas parce que l'information n'existe tout simplement pas mais parce que elle n'existe pas encore à l'instant de la création de la ligne. Donc, si je suis votre raisonnement, sachant que tôt ou tard, une date sera saisie, elle devrait être paramétrée comme vide et non pas comme NULL.
    Vide n'est applicable que pour des types (n)(var)char. Pour les dates de fin, je préfère la valeur '9999-12-31' par défaut comme expliqué précédemment.



    Citation Envoyé par Nerva Voir le message
    Et avec le nom de jeune fille :

    - Pour un homme, il ne sera jamais rempli : c'est donc un NULL.
    - Pour une femme, il sera peut-être rempli un jour : c'est donc un vide.
    Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide et non pas null, null signifie "on n'a pas l'information, on ne sait pas". Or là, on sait.
    Null est applicable au contraire pour une femme mariée dont on a le nom marital : l'absence du nom de naissance est un manque d'information, donc "null".



    Citation Envoyé par Nerva Voir le message
    @escartefigue. Je reviens au sujet initial. Dans la dernière structure que tu as présentée, avec type et sous-types, la date de fin n'est pas indiquée. Elle est pourtant obligatoire pour différencier les partenariats en cours et terminés et pouvoir appliquer les règles de gestion, que je rappelle de manière plus complète :
    C'est tout simplement parce que je n'ai communiqué qu'un MCD minimaliste, il faut évidemment l'enrichir avec les attributs qui vont bien :
    on a besoin d'une date de fin, il suffit de l'ajouter dans l'association (ENC_encadrer)

  8. #28
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Alors je comprends la subtilité du raisonnement, mais j'y vois quand même des failles.

    D'abord, la femme. Le nom de naissance que l'on ne possède pas existe pourtant bel et bien, contrairement par exemple à la couleur du toit d'un vélo, qui lui, on en est sûr et certain, n'existera jamais.

    Ensuite, et c'est là que ça coince, je te cite :

    "Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide"

    "Null est applicable au contraire pour une femme mariée dont on a le nom marital : l'absence du nom de naissance est un manque d'information, donc "null"."

    Dans une table contenant les coordonnées des employés, figurent les hommes et les femmes. La colonne "Nom de naissance" (comme les autres) étant commune aux deux sexes, comment, selon le cas, va-t-on définir que la "cellule" est vide ou NULL ?

    Ensuite, j'arrête là...

    -----

    Pour ce qui est de mon affaire, reste une question, quelle est la meilleure méthode : table commune avec association réflexive ou tables avec sous-types ?

  9. #29
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 583
    Billets dans le blog
    10
    Par défaut
    dans le cas où des hommes et des femmes sont présents, on utilise une colonne nullable, laissée à "null" dans un cas et alimentée à vide dans l'autre, tout simplement

    D'une façon plus générale :

    • je ne sais pas => marqueur "null"
    • je sais qu'il n'y a pas de valeur pour cet attribut ==> valeur vide

  10. #30
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    dans le cas où des hommes et des femmes sont présents, on utilise une colonne nullable, laissée à "null" dans un cas et alimentée à vide dans l'autre, tout simplement
    Même si je n'en vois pas l'intérêt, j'avais parfaitement compris ce principe. Mais c'est la manière dont on alimente à vide une colonne NULL qui m'interpelle. L'employé de bureau ne saisit pas ses données avec un script SQL de remplissage.

    Donc, encore une fois, comment, à partir du formulaire de saisie d'un logiciel transforme-t-on une cellule NULL en vide ?

    On saisit deux fiches de personnes :

    Dupont, [pas de nom de jeune fille], Catherine pour la dame.
    Durant, [pas de nom de jeune fille], Pierre pour le monsieur.

    La colonne 2 ayant une valeur par défaut NULL, comment la métamorphose-t-on en vide pour le monsieur en ne saisissant rien ?

  11. #31
    Expert confirmé
    Homme Profil pro
    Responsable Données
    Inscrit en
    Janvier 2009
    Messages
    5 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : Janvier 2009
    Messages : 5 392
    Par défaut
    Peut-être avec une coche "non renseigné", où dans le cas d'une liste de sélection une valeur "N/A", "inconnu"...
    Et c'est le code derrière le formulaire qui va interpréter cette info pour mettre à null la colonne correspondante.

    Tatayo.

  12. #32
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Citation Envoyé par tatayo Voir le message
    Peut-être avec une coche "non renseigné", où dans le cas d'une liste de sélection une valeur "N/A", "inconnu"...
    Et c'est le code derrière le formulaire qui va interpréter cette info pour mettre à null la colonne correspondante.
    Ok, là d'accord. Mais quel intérêt de préciser une telle évidence ? Tout le monde sait qu'un homme n'a pas de nom de jeune fille et qu'une femme qui l'indique signifie qu'elle est mariée.

  13. #33
    Expert confirmé
    Homme Profil pro
    Responsable Données
    Inscrit en
    Janvier 2009
    Messages
    5 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : Janvier 2009
    Messages : 5 392
    Par défaut
    Citation Envoyé par Nerva Voir le message
    Ok, là d'accord. Mais quel intérêt de préciser une telle évidence ? Tout le monde sait qu'un homme n'a pas de nom de jeune fille et qu'une femme qui l'indique signifie qu'elle est mariée.
    En fait si, chacun des époux peut prendre le nom de l'autre époux: voici le texte de loi correspondant.

    Quoi qu'il en soit j'ai un exemple très concret (malheureusement ).
    J'ai un exemple très concret: lors de la création d'une fiche client en magasin, l'adresse email était facultative => NULL en cas d'absence.

    Un jour la direction a décidé que l'adresse email devenait obligatoire (RGPD ? V.R.A.F.). Idée géniale s'il en est .
    Comme le formulaire vérifiait la syntaxe de l'adresse, on ne pouvait pas saisir d'adresse vide. Du coup les vendeurs ont saisie des adresses "bidon", parfois avec un domaine valide, parfois non, et notre base client s'est retrouvée quelque peu "pourrave", et il est quasiment impossible de nettoyer ces adresses, à part les traiter au cas par cas.

    Donc un NULL ici a toute sa place.

    Tatayo.

  14. #34
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Pour le nom d'époux, les lois ont effectivement changé ; je me suis contenté de prendre un exemple ancien mais valide dans la pratique.

    D'accord pour ton exemple, c'est du concret. Reste à mettre en doute, pour ce cas précis, le bien-fondé de la direction. Qu'à partir de telle date, l'adresse email devienne obligatoire pour les nouveaux inscrits, ok, mais alors, saisir des adresses bidon juste pour dire que les cases soient remplies, drôle d'idée... Par exemple, en vue d'une opération promotionnelle, comment contacter les anciens clients autrement que par courrier papier ? Comment différencier les anciens clients avec une adresse valide de ceux avec une adresse bidon ?

  15. #35
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 992
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 992
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Nerva Voir le message
    ...
    D'abord, la femme. Le nom de naissance que l'on ne possède pas existe pourtant bel et bien, contrairement par exemple à la couleur du toit d'un vélo, qui lui, on en est sûr et certain, n'existera jamais.
    [...]
    "Pour un homme, on sait que c'est inapplicable, on a l'information, c'est donc vide"
    Sexisme et acculturation sont les deux mamelles du désastre.... Même s'il est courant que l'homme impose son patronyme au moment du mariage, ce n'est qu'une coutume et non de droit. le mari peut adopter le nom de son épouse. La notion de nom marital est, depuis des lustres remplacée officiellement par le terme "nom d'usage"...
    https://www.service-public.fr/partic...vosdroits/F868

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #36
    Expert confirmé
    Homme Profil pro
    Responsable Données
    Inscrit en
    Janvier 2009
    Messages
    5 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : Janvier 2009
    Messages : 5 392
    Par défaut
    Citation Envoyé par Nerva Voir le message
    D'accord pour ton exemple, c'est du concret. Reste à mettre en doute, pour ce cas précis, le bien-fondé de la direction.
    C'est bien ce que nous avions fait, freiner des 4 fers, mais rien n'y a fait.
    Citation Envoyé par Nerva Voir le message
    Qu'à partir de telle date, l'adresse email devienne obligatoire pour les nouveaux inscrits, ok…
    Bha non, un client peut très bien refuser de donner son adresse email.
    Citation Envoyé par Nerva Voir le message
    , mais alors, saisir des adresses bidon juste pour dire que les cases soient remplies, drôle d'idée…
    Les vendeurs n'avaient malheureusement pas d'autre choix.
    Citation Envoyé par Nerva Voir le message
    Par exemple, en vue d'une opération promotionnelle, comment contacter les anciens clients autrement que par courrier papier ?
    Le client s'exclue de fait de la campagne d'infos, c'est son choix.
    Citation Envoyé par Nerva Voir le message
    Comment différencier les anciens clients avec une adresse valide de ceux avec une adresse bidon ?
    C'est toute la difficulté, autant un domaine inexistant est identifiable (il suffit de chercher le MX correspondant), autant une adresse du genre bidon@free.fr est invérifiable.

    Tatayo.

  17. #37
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    @SQLPro : ce n'était qu'un exemple. Je ne me suis pas creusé la tête pour en trouver un autre.

    Citation Envoyé par tatayo Voir le message
    Bha non, un client peut très bien refuser de donner son adresse email.
    Je ne fais que te citer : "Un jour la direction a décidé que l'adresse email devenait obligatoire"

    Perso je ne donne pas non plus mon adresse email à un magasin qui ne paramètre pas par défaut le non-envoi de spams publicitaires... c'est-à-dire que je ne la donne à aucun ! Même si il n'y a qu'à cocher une case (quand ça veut bien marcher !) pour ne plus rien recevoir, c'est une question de principe.

  18. #38
    Membre éclairé Avatar de Nerva
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    391
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 391
    Par défaut
    Je reviens au sujet initial pour une précision...

    Dans le but d'obtenir dans une requête la liste de tous les internes et de leur(s) externe(s) avec une cellule vide lorsque l'externe est inexistant, j'ai modifié (et simplifié ici) les tables :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    CREATE TABLE T_INDIVIDUS (
    	IND_ID INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1) NOT NULL,
    	IND_TYPE INTEGER NOT NULL,
    	IND_NOM VARCHAR (50) NOT NULL,
    	IND_PRENOM VARCHAR (50) NOT NULL,
    	CONSTRAINT PK_IND_ID PRIMARY KEY (IND_ID)
    );
     
    CREATE TABLE T_PARTENARIATS (
    	INT_ID INTEGER NOT NULL,
    	EXT_ID INTEGER DEFAULT NULL,
    	CONSTRAINT PK_INT_ID PRIMARY KEY (INT_ID),
    	CONSTRAINT FK_INT_ID FOREIGN KEY (INT_ID) REFERENCES T_INDIVIDUS (IND_ID),
    	CONSTRAINT FK_EXT_ID FOREIGN KEY (EXT_ID) REFERENCES T_INDIVIDUS (IND_ID),
    	CONSTRAINT UC_INT_EXT UNIQUE (INT_ID, EXT_ID)
    );
    Ainsi que le jeu de données avec ajout d'une colonne INT_TYPE (1 interne, 2 externe) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (1, 1, 'Talbot', 'Maribelle');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (2, 1, 'Vidal', 'Pierre');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (3, 1, 'Nemours', 'Doralice');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (4, 1, 'Grimaud', 'Sarah');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (5, 1, 'Vassent', 'David');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (6, 1, 'Carpentier', 'Thomas');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (7, 1, 'Lefort', 'Julie');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (8, 1, 'Jodel', 'Karine');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (9, 2, 'Montepin', 'Victor');
    INSERT INTO T_INDIVIDUS (IND_ID, IND_TYPE, IND_NOM, IND_PRENOM) VALUES (10, 2, 'Lasalle', 'Anne-Marie');
    De 1 à 8 : internes
    De 2 à 10 : externes

    Pour que ça fonctionne, ça implique de saisir obligatoirement chaque interne dans T_PARTENARIATS avec un NULL dans la colonne EXT_ID lorsqu'il n'y a pas de partenariat. Exemple avec ce jeu :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (1, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (2, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (3, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (4, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (5, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (6, NULL);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (7, 9);
    INSERT INTO T_PARTENARIATS (INT_ID, EXT_ID) VALUES (8, 10);
    Ainsi, cette requête retourne ce que je désire :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SELECT
    (I1.IND_NOM || ' ' || I1.IND_PRENOM) AS INTERNE,
    (I2.IND_NOM || ' ' || I2.IND_PRENOM) AS EXTERNE
    FROM T_PARTENARIATS P
    INNER JOIN  T_INDIVIDUS I1 ON I1.IND_ID = P.INT_ID
    LEFT OUTER JOIN  T_INDIVIDUS I2 ON I2.IND_ID = P.EXT_ID
    Je pourrais ainsi ensuite ajouter d'autres tables, comme les adresses, les localités, afin de faire des "mailings", par exemple.

    N'y aurait-il pas malgré tout une autre manière de procéder, plus académique, qui éviterait la saisie lorsqu'il n'y a pas de partenariat ?

  19. #39
    Expert confirmé
    Homme Profil pro
    Responsable Données
    Inscrit en
    Janvier 2009
    Messages
    5 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : Janvier 2009
    Messages : 5 392
    Par défaut
    Bonjour,
    Tu peux partir de la table individus pour récupérer les internes, puis faire une jointure externe sur la table partenariat puis sur individus pour avoir les externes liés:
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    Select *
    From individus as int
    Left outer join partenariat as p
    Inner join individus as ext
    On p.idext = ext.id
    On p.idint = int.id
    Where ext.type = 1
    Je simplifie, c'est galère de taper sur une tablette... Mais c'est l'idée.

    Tatayo

  20. #40
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 583
    Billets dans le blog
    10
    Par défaut
    Ces tables simplifiées :

    Citation Envoyé par Nerva Voir le message
    Je reviens au sujet initial pour une précision...

    Dans le but d'obtenir dans une requête la liste de tous les internes et de leur(s) externe(s) avec une cellule vide lorsque l'externe est inexistant, j'ai modifié (et simplifié ici) les tables :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    CREATE TABLE T_INDIVIDUS (
    	IND_ID INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1) NOT NULL,
    	IND_TYPE INTEGER NOT NULL,
    	IND_NOM VARCHAR (50) NOT NULL,
    	IND_PRENOM VARCHAR (50) NOT NULL,
    	CONSTRAINT PK_IND_ID PRIMARY KEY (IND_ID)
    );
     
    CREATE TABLE T_PARTENARIATS (
    	INT_ID INTEGER NOT NULL,
    	EXT_ID INTEGER DEFAULT NULL,
    	CONSTRAINT PK_INT_ID PRIMARY KEY (INT_ID),
    	CONSTRAINT FK_INT_ID FOREIGN KEY (INT_ID) REFERENCES T_INDIVIDUS (IND_ID),
    	CONSTRAINT FK_EXT_ID FOREIGN KEY (EXT_ID) REFERENCES T_INDIVIDUS (IND_ID),
    	CONSTRAINT UC_INT_EXT UNIQUE (INT_ID, EXT_ID)
    );

    Né répondent pas aux règles de gestion initialement exprimées :

    Citation Envoyé par Nerva Voir le message
    Bonjour.

    Soit une population d'individus. Il y a les internes, qui font partie d'un organisme (société, entreprise, administration, c'est sans importance) et les externes, qui sont des vacataires en partenariat avec des internes pour des missions temporaires.

    - 1 interne peut avoir 0 ou 1 externe à la fois. Une date de début et de fin sont précisées à cet effet.
    - 1 externe (qui n'existe que si il est missionné au moins 1 fois) peut être en partenariat avec 1 ou plusieurs internes, simultanément.
    La clef primaire de la table partenariat est INT_ID qui référence IND_ID, donc un indentifiant d'interne ou d'externe puisqu'il n'y a pas de restriction sur le type d'individu.
    Ce faisant, on ne peut ni lier un interne à plusieurs externes à des dates différents (viol de la règle 1), ni avoir plusieurs associations entre un interne et des externes (viol de la règle 2).

Discussions similaires

  1. [Bénévole] webmaster pour association
    Par as.sc.fr dans le forum Autres
    Réponses: 0
    Dernier message: 26/01/2008, 13h43
  2. Une boucle pour associer X actions à X checkbox
    Par nicolas2603 dans le forum ActionScript 1 & ActionScript 2
    Réponses: 1
    Dernier message: 17/10/2007, 14h05
  3. Besoin petite aide pour association
    Par ptityop dans le forum Autres
    Réponses: 0
    Dernier message: 09/10/2007, 16h23
  4. pb pour associé un fichier chm avec un projet MFC
    Par Cédric_07 dans le forum MFC
    Réponses: 9
    Dernier message: 05/12/2006, 15h56
  5. Réponses: 2
    Dernier message: 26/07/2006, 12h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo