Discussion :

[Erique1]

Bonjour,
J'aimerais si possible avoir de l'aide pour faire une requête sur IBM DB2 ; je travaille, en tant qu'étudiant sur un projet immobilier. j'ai 3 tables


Des erreurs apparaissent quand je lance ma requête ( je cherche à trouver la Liste des communes où le nombre de ventes a augmenté d'au moins 20% entre le premier et le second trimestre de 2020)
.

Les 2 sous requêtes donnent bien des resultats , je pense que les problemes vienennt de la fin dans la division si le nb de ventes du 1er trim est de 0 ; ou bien la nomination des colonnes ambigues...

Où si vous suggérez une autre façon d’écrire cette requête je suis preneur

Merci

[al1_24]

Bonjour,

Les requêtes et leur résultat sont totalement illisibles sur un petit écran.
Merci de poster le code sous forme d'un bloc de code (utiliser le bouton code (#) juste au dessus de la zone de saisie des messages) dans le message.

[escartefigue]

Et accessoirement, j'espère que cette base de données n'est pas encore en production

• Les PK de type VARCHAR sont ce qu'on peut faire de pire (id_commune, id_bien_immo)
• Une même typologie pouvant correspondre à plusieurs locaux, on devrait avoir une table de typologie des locaux en lien avec les locaux
• Du VARCHAR(3) ça ne devrait jamais être utilisé : l'attribut de longueur va ajouter ici un octet soit une longueur de 4 maxi.
  
  On a donc une longueur supérieure à du char fixe et en même temps les inconvénients liés au varchar
• Le code commune, s'il s'agit du code insee, vient d'un référentiel externe, il ne faut donc surtout pas le définir dans un type numérique, même si aujourd'hui les valeurs sont toutes numériques : tout référentiel externe peut changer de type et le jour où ça arrivera, vous aurez à modifier votre base ! (C'est arrivé il y a quelques années avec les codes départements lors de l'ajout des codes 2A et 2B pour la corse)

S'il n'est pas trop tard, revoyez complètement la modélisation !

[vazymimil]

Bonjour,

Même si je vois le code j'aimerai pouvoir le copier/coller et le formater pour le rendre plus lisible, et ne vais certainement pas me taper toute la saisie pour une proposition de correction.

Ceci dit comme je le vois :
La raison de l'erreur est que la colonne n'existe pas avec VENTE au singulier tel qu'écrit dans le where final.
Mais il y a plusieurs autres erreur :

• en SQL la division de deux entier c'est la division entière, sans décimale donc, pour avoir une décimale il faut forcer le type de l'une des deux opérandes soit par un CAST soit en la multipliant par un nombre de type non entier comme 1.0.
• le select final est un produit cartésien, la requête compare les ventes du 1er trimestre d'une commune avec les vente du deuxième trimestre de chaque commune, il faut faire des jointures et éviter autant que possible la notation avec les virgules très peu lisible et plutôt passer par des jointures explicites
• le select final fait référence à une colonne C.COMMUNE alors que C n'est pas définie dans le contexte

Pour le formatage, même si ça n'est pas toujours concluant avec SQL d'appliquer une méthode systématique, il y a des outils en ligne (chercher SQL formatter) qui permettent de faire en sorte que la plupart du temps ça soit lisible.

Et comme il y a utilisation de CTE, autant leur donner un nom parlant comme T1 et T2 et faire par (T2.ventes - T1.ventes) * 1.0 / T1.ventes

[Erique1]

Bonjour vazymimil, escartefigue, etal1_24

je vous remercie tous d'avoir pris le temps de m'aider et effectivement ça m'a bien aidé.
Car avec la jointure .... j'ai pu obtenir un résultat Ouf enfin....
- entre temps, j'avais corrigé pour le S de vente; mais ca n'avait pas suffi
- "C" est défini dans la table3 et la table 4 , fallait -il aussi le definir dans le dernier select ?
- je suis d'accord pour le type varchar en PK moi j'avais mis integer, mais mon mentor m'a fait changer en mettant varchar (!)

Et je prends note de tous vos conseils : pour ce type de variable varchar, le code commune INSEE à ne jamais mettre en numérique ; la nomination des tables ; l'utilsiation de SQLformater
J'ai commencé il y a 2 mois et je sais que la route sera longue avant de maîtriser tout cet univers .

[escartefigue]

je suis d'accord pour le type varchar en PK moi j'avais mis integer, mais mon mentor m'a fait changer en mettant varchar (!)

Je suis curieux de connaître les arguments du "mentor" !

[vazymimil]

Bonjour vazymimil, escartefigue, etal1_24

- "C" est défini dans la table3 et la table 4 , fallait -il aussi le définir dans le dernier select ?

Des noms qui sont définis à l'intérieur d'un CTE, seuls persistent les nom de colonnes sélectionnées dans les requêtes qui utilisent les CTE, qualifiables par le nom de la CTE. Donc oui pour utiliser un nom d'ensemble de données C il faut d'abord le définir dans le contexte. D'ailleurs si C pointait vers les communes dans l'une des CTE et les clients dans une autre, comment le moteur SQL aurait pu alors deviner lequel était le bon.
Après comme l'id de commune était déjà présent dans les deux, que chacune des CTE contient chaque id de commune ayant au moins un bien et qu'aucune colonne autre que l'id n'était sélectionné alors la table n'est pas nécessaire dans le select final.
Et comme chacune des CTE ne contient au plus qu'une fois un ID de commune, le GROUP BY sur le select final est superflu, et n'est cohérent qu'avec le produit cartésien qui n'a pas a être là, et j'imagine que le GROUP BY n'est plus là dans la version corrigée. Si une personne (y compris l'auteur) devait maintenir la requête dans quelques années et voyait ce GROUP BY, elle chercherait à comprendre la subtilité et y perdrait du temps.

[Erique1]

rebonjour,

Effectivement , il y a , pour moi beaucoup de subtilités , et je cherche à comprendre la logique du SGBDR; "pourquoi il y a une ambiguïté ? ", "pourquoi ile veut pas de ça ?" il faut se mettre à sa place en fait.
j 'avais testé plein de possibilités , ajouter par ci par là des choses (comme le GROUP BY) car je n'arrivais plus à rien en réfléchissant , donc oui, je l'ai enlevé.

Si j'ai bien compris, pour mon mentor, (à qui j'ai fait remarquer qu'aucun autre étudiant de notre plateforme de travail ne mettait VARCHAR en PK) , il me dit que tout ce qui n'est pas calculable, quantifiable , comme des codes (communes, départements..) doit être en varchar . Je me dis que ca va dans le sens de ce que vous disiez , car là en fait pour id_bien_immo et id_commune, ces 2 PK sont des concaténations d'attributs constitués de chiffres et de rares fois de lettres.
Alors que pour id_vente, c'est une integer auto-incrementé.
et moi j'avais créé pareillement des Pk integer autoincrementées pour les 3 tables au debut. Mais il m'a fait changer, peut être pour me faire faire des concatenations ...

Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?

[escartefigue]

Si j'ai bien compris, pour mon mentor, (à qui j'ai fait remarquer qu'aucun autre étudiant de notre plateforme de travail ne mettait VARCHAR en PK) , il me dit que tout ce qui n'est pas calculable, quantifiable , comme des codes (communes, départements..) doit être en varchar . Je me dis que ca va dans le sens de ce que vous disiez , car là en fait pour id_bien_immo et id_commune, ces 2 PK sont des concaténations d'attributs constitués de chiffres et de rares fois de lettres.
Alors que pour id_vente, c'est une integer auto-incrementé.
et moi j'avais créé pareillement des Pk integer autoincrementées pour les 3 tables au debut. Mais il m'a fait changer, peut être pour me faire faire des concatenations ...

La première qualité d'une PK c'est d'être stable : sa valeur se propage en cascade dans d'autres tables au travers des FK, il ne faut donc pas qu'elle fasse l'objet de mises à jour. C'est pour cette raison qu'on choisit le plus souvent une colonne "identity" attribuée par le SGBD. Une telle colonne, dénuée de sens, n'a aucune raison d'être modifiée. A l'inverse, un code commune peut changer (ça se produit régulièrement : des communes fusionnent à peu près à chaque élection municipale). Donc, la bonne démarche est celle que vous aviez choisie : définir une PK asémantique de type "identity" et donc integer (small integer suffit en l'occurrence) et définir une autre colonne non PK mais avec une contrainte unique et de type CHAR(5) et non pas VARCHAR(5) aussi encombrant que du CHAR pour cette taille et moins performant !.
De plus, un integer c'est 4 octets pour 4 294 967 295 valeurs possibles alors qu'un char ou varchar prendra 5 octets et beaucoup moins de valeurs possibles.
Enfin, les CHAR et VARCHAR sont sensibles à la collation contrairement aux types numériques, c'est donc très risqué.
Votre "mentor" serait bien avisé d'apprendre les avantages et les inconvénients du VARCHAR, s'il existe deux types CHAR et VARCHAR c'est qu'il y a une raison !
Il serait également bien avisé d'apprendre quelles sont les qualités requises d'une PK, c'est essentiel. Une PK mal construite c'est des traitements inutilement couteux et une surcharge disque, réseau et CPU...

Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?

En effet, c'est le rôle des alias de table et de colonne que de lever ces ambiguïtés.

[vazymimil]

Effectivement , il y a , pour moi beaucoup de subtilités , et je cherche à comprendre la logique du SGBDR; "pourquoi il y a une ambiguïté ? ", "pourquoi ile veut pas de ça ?" il faut se mettre à sa place en fait.

Oui il y en a pas mal, le coup de la division entière, les comparaisons avec null qui donne UNKNOWN, etc, et parfois des messages d'erreur n'arrangent rien. Il faut se mettre à sa place en effet, mais pour ça il faut la connaître, parfois on ne comprend le sens du message qu'en connaissant bien la syntaxe, par exemple en DB2LUW where exist(select * from a) au lieu de where exists(select * from a) est compris comme un appel d'une fonction exist avec comme paramètre la multiplication des colonnes select et from et une erreur de syntaxe, le a, un éditeur avec colorisation trouvera select et from, les colorisera comme des mots clés.

j 'avais testé plein de possibilités , ajouter par ci par là des choses (comme le GROUP BY) car je n'arrivais plus à rien en réfléchissant , donc oui, je l'ai enlevé.Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?

On est effectivement vite tenté de mettre des group by ou des distinct quand on a pas le résultat qu'on veut, mais ne pas savoir pourquoi on le met est mauvais signe, j'ai vu aussi souvent des select distinct(a), b from c, la personne semble penser qu'elle n'aura qu'une fois a et sans doute le premier alors qu'il y a aucune différence avec select distinct a, b from c.
Comme le dit escartefique, c'est par les alias qu'on lève ces ambiguïtés. Après selon le SGBD les erreurs peuvent être trompeuses, par exemple si DB2 for I se plein que COLONNE1 n'existe pas, c'est peut être que A n'existe pas dans A.COLONNE1, DB2LUW lui dit que c'est A.COLONNE1 qui n'existe pas ce qui au moins ne met pas sur une mauvaise voie.
Au delà des ambiguïtés, bien nommer et bien structurer les choses en SQL comme ailleurs est important pour bien comprendre ce qu'on fait, avec SQL on peut faire des requêtes complexes, parfois d'autant plus complexes qu'on a du mal à définir précisément ce qu'on veut.
Et qualifier les colonnes dans la requête même quand il n'y a pas ambiguïté permet à quelqu'un qui découvre une requête de savoir de quelles tables viennent les colonnes sans aller chercher à chaque fois dans un diagramme

Les alias et le formatage permettent de faire d'une requête parfaitement valide pour DB2LUW

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

with from(from) as (values 'from'), select(select) as (values  'select') select select select from select select (select) union select from from from from (from)

Une requête stupide mais lisible assez rapidement pour un humain, ou au moins on a pas de question à se poser si un mot est une table une colonne un alias ou un mot clé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
WITH
  from(from) AS (VALUES 'from'),
  select(select) AS (VALUES 'select')
SELECT
  select.select AS select
FROM select AS select (select)
UNION
SELECT
  from.from AS from
FROM from AS from (from)

[Erique1]

Merci encore pour vos conseils, et l'aide à ma résolution de problème bien sûr . j'ai hâte de maitriser comme vous le sujet

Là, on a un projet avec des données sur un problème de santé publique, (nutrition dans le monde), et on doit choisir R ou Python. Lequel conseilleriez vous pour un novice ? j'ai le les cours préconisés sur les 2 langages, masi ne sait pas si l'un serait plus adapté ( à moi, débutant et :ou au thème abordé) ou peu importe ?

[vazymimil]

Je ne maitrise que quelques bases Python et rien de R, donc perso pas même un début d'avis sur la question.