Discussion :

[clavier12AZQSWX]

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.

[tatayo]

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.

[SQLpro]

Il n'y a pas besoin de parenthèses pour entourer les cases...

[clavier12AZQSWX]

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

[tatayo]

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.