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 :

Peut-on utiliser un coalesce de champ dans le SET d'une requête UPDATE ?


Sujet :

Langage SQL

  1. #1
    Membre éclairé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    avril 2009
    Messages
    1 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : avril 2009
    Messages : 1 071
    Points : 712
    Points
    712
    Par défaut Peut-on utiliser un coalesce de champ dans le SET d'une requête UPDATE ?
    bonjour,

    j'ai une table avec une structure particulière, je simplifie pour vous expliquer :

    id
    nom
    rdv1
    rdv2
    rdv3

    les champs rdv sont des champs date.

    je veux pouvoir mettre à jour la ligne en plaçant une date dans le 1er champs rdv dispo (donc non-rempli).
    Le souci c'est que je sais pas quel champ rdv1 ou rdv2 ou rdv3 est libre.

    techniquement j'aimerais faire ça :

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    UPDATE matable SET not coalesce (rdv1,rdv2,rdv3) = '2022-01-14' WHERE id=45
    dans mon "rêve", je voudrais que " not coalesce (rdv1,rdv2,rdv3)" me renvoit le nom du premier champ null afin qu'il soit updaté !
    Puisque coalesce renvoie la premiere donnée non-null, ce serait super que NOT coalesce renvoit le 1er champs NULL ..... Mais ça ne fonctionne pas hélas!

    du coup, comment faire en SQL sans utiliszer PHP et checké 1 à 1 chaque attribut rdv_x pour déterminer lequel mettre à jour ...
    peut-être il existe une syntaxe ou fonction genre "first-not-null-field' qui renvoie le 1er champs non null dans une liste que je fournis ?

    merci de vos idées.

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 726
    Points : 11 359
    Points
    11 359
    Par défaut
    Bonjour,
    Tu ne peux pas… et tu paies une modélisation qui me semble un peu bancale.

    Mais tu peux faire une pirouette du genre:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    update MaTable
    set col1 = (case when col1 is null then 'MaValeur' else col1 end),
    col2 = (case when col1 is not null and col2 is null then 'MaValeur' else col2 end),
    col3 = (case when col1 is not null and col2 is not null and col3 is null then 'MaValeur' else col3 end),
    ...
    Avec 3 colonnes c'est encore jouable, mais ça risque de se compliquer à mesure que le nombre de colonnes augmente !

    Tatayo.

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 988
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 988
    Points : 49 813
    Points
    49 813
    Billets dans le blog
    1
    Par défaut
    Il n'y a pas besoin de parenthèses pour entourer les cases...
    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/ * * * * *

  4. #4
    Membre éclairé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    avril 2009
    Messages
    1 071
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : avril 2009
    Messages : 1 071
    Points : 712
    Points
    712
    Par défaut
    et tu paies une modélisation qui me semble un peu bancale.
    oui cela je l'ai compris... hélas on est pas tous maître du travail en amont...

    Justement je me suis posais la question, comment une situation basique "gestion de 3 entretiens" devrait être traitée en sgdb relationnel ?
    une relation avec les 3 champs VS une relation avec un tuple par entretien + une relation avec une table maître.

    dans la vie courante, on va faire de requête du genre "chercher les gens ayant eu le 2eme entretien", avec la solution1 on fait un basique select where rdv<>null , alors qu'avec la solution 2 (supposée idéal), on fera un select where..count=2 Or le count est bien plus consommateur de ressource non ?

    Idem, dans la vie courante, quand on va vouloir ajouter une date de 2eme rdv, il va falloir compter avant pour être sûr qu'on ne n'ajoute pas le 3eme rdv alors qu'en solution1, on faut juste un update du champs rdv2 ...



    en fait mathématiquement, j'ai du mal à comprendre pourquoi il vaut mieux faire la solution 'enseignée' :
    personne (id , nom)
    rdv (id, date)
    que la solution 'pratique'
    personne (id, nom, rdv1,rdv2,rdv3)

    si quelqu'un a une fiche de cours SIMPLE qui démontre par a+b, ça m'intéresse....

    merci

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 726
    Points : 11 359
    Points
    11 359
    Par défaut
    Et bien regarde déjà la requête qu'il faut pondre pour un problème somme toute assez simple.


    Autre cas, si tu veux passer de 3 à quatre rendez-vous, il faut modifier la structure de la table, et revoir toutes les requêtes qui y accèdent.
    Si tu veux supprimer un rendez-vous, il faut décaler le contenu des autres colonnes, alors qu'avec une table de relation il suffit de supprimer la ligne.
    Si tu veux avoir la liste des personnes qui ont un rendez-vous à une date donnée, il faut interroger les 3 colonnes avec des OR (ou une succession de COALESCE), au lieu d'une simple égalité.

    Et avec une table de relation, tu peux indexer la colonne date, indexation qui sera plus problématique avec 3 colonnes.
    Si tu indexes séparément chaque colonne rendez-vous, il n'est pas certains que le SGBD utilisé sera à même d'utiliser les 3 indexes. Surtout avec une pile de COALESCE.

    Pour finir, avec une table de relation tu peux ajouter des données complémentaires aux rendez-vous (lieu, commentaire...).

    Tatayo.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [2012] Utilisation de noms de champs dans un paramètre
    Par Zolyne dans le forum SSRS
    Réponses: 1
    Dernier message: 22/09/2014, 11h02
  2. Utilisation d'un champ dans un set analysis
    Par Davidb_ dans le forum QlikView
    Réponses: 6
    Dernier message: 28/04/2014, 19h33
  3. Réponses: 4
    Dernier message: 02/09/2011, 17h06
  4. Réponses: 4
    Dernier message: 17/01/2007, 16h48
  5. Réponses: 9
    Dernier message: 05/07/2005, 09h37

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