Discussion :

[Pach30]

Bonjour

Je n'ai de compétences SQL et je galère donc un peu pour faire ce je souhaite .

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
create table T_Experience as (
select pot.id as PotID, pot."potNumber" as PotNumero,  
		pc."day" as Jour, pc."cycleNumber" as Numcycle,
               pp.number as NumPompe ,
	  	wa."wateringType" as TypeArrosage , wa.percent as ratioA  ,wa.volume as ConsA  
	from "T_Table_pot" pot 
       join  "wateringscenario" ws on pot.watering_scenario_id = ws.id 
	 join "wateringinstructions" wi on wi.watering_scenario_id =ws.id
	join "wateringinstructions_watering_activation"  wawi ON wawi.wateringinstructions_id = wi.id
	join "wateringactivation" wa ON wa.id = wawi.wateringactivation_id
	join "pump" pp ON pp.id = wa.pump_id 
	join "Pcycle" pc on pc.id =wi."cycle_id"
    order by pot."potNumber" ASC ,  pc.day  asc  , pc."cycleNumber" asc );

Je ne sais pas cette requête est bien orthodoxe mais elle me permet de d'obtenir une ligne d'instruction pour chaque 'pot' par jour et par cycle. A partir d'elle , je peux créer des fichiers CSV que je transfère dans un automate . Sauf que je viens de m'apercevoir que je peux avoir de 1 à 4 pompes par cycle alors que ma requete ne m'en donne qu'une , certes avec un id .

Comment puis je modifier cette requete pour systématiquement avoir une colonne pour chaque pompe et alors mettre les bons paramétres (typeArrosage/ratioA/consA) pour chaque pompe selon le(s) pump id?

Je ne peux pas modifier la base de donnée qui est issue d'une site sous Django

Merci d'avance pour votre aide et vos conseils

[escartefigue]

Bonjour,

S'il peut y avoir au maximum 4 pompes, il faut faire 4 jointures externes (OUTER JOIN) sur la table des pompes avec un alias de table différent à chaque fois.

Exemple :

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
17
18
19
select pot.id        as PotID
     , pot.potNumber as PotNumero,  
[...]
from T_Table_pot pot 
inner join wateringscenario ws 
   on ws.id = pot.watering_scenario_id
[...]
left join pump PP1
   on pp1.id = wa.pump_id 
left join pump PP2
   on  ?
left join pump PP3
   on  ?
left join pump PP4
   on  ?
order by pot.potNumber  ASC
      ,  pc.day         asc
       , pc.cycleNumber asc
;

Reste à savoir sur quels critères faire les 4 jointures

Note : il ne faut pas utiliser de doubles quotes (guillemets) pour encadrer les noms d'objets (noms de tables, de colonnes, de trigger, de procédures...).

[Pach30]

Merci Escartefigue pour cette réponse rapide !
J'avoue que je m'y perds entre les guillemets et les simple quotes.
J'ai passé, bon gré mal gré, une bonne partie de la nuit à tenter de trouver une solution à mon problème . J'ai imaginé explorer la piste des unions car ce je veux c'est avoir une table avec systématiquement mes 4 pompes dont seule 1 ou plusieurs sont utilisés. Mais il est facile pour moi de dire dans l'automate que si telle valeur est à zéro , c'est que la pompe n'est pas utilisée .
Je vois ma requête commencer comme cela

Code :

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

1
2
3
4
5
6
7
8
9
 
select pot.id as PotID, pot."potNumber" as PotNumero,  
		pc."day" as Jour, pc."cycleNumber" as Numcycle,
//               pp.number as NumPompe ,
	  	wa."wateringType" as TypeArrosageP1 , wa.percent as ratioA_P1  ,wa.volume as ConsA_P1  
              wa."wateringType" as TypeArrosageP2 , wa.percent as ratioA_P2  ,wa.volume as ConsA_P2  
             wa."wateringType" as TypeArrosageP3 , wa.percent as ratioA_P3  ,wa.volume as ConsA_P3           
            wa."wateringType" as TypeArrosageP4 , wa.percent as ratioA_P4  ,wa.volume as ConsA_P4  
from "T_Tablepot" pot

la ou je coince , c'est comment créer ces 4 jeux de paramétres en tant que colonne . dans ma requete initiale , j'en ai un jeu car j'extrait le numéro de la pompe mais finalement , il faudrait que que je le fasse systématique pour chaque pompe

Je vais explorer la piste que vous m'avez indiqué .

ah ,j'ai une autre contrainte lié à l'automate , c'est que les fichiers CSV ( j'en fais un par jour et par cycle contentant l'ensemble des pots ) que je génére à partie de cette table ne doivent pas dépasser 65 Ko.


Merci

[escartefigue]

il faut communiquer le modèle de données afin de nous permettre de comprendre comment sont liées la table de pompes et les autres tables.
A partir de là, il sera facile de trouver les jointures qui vont bien

[Pach30]

Quand vous écrivez le modèle de données , vous entendez la description de la base et des tables ?
j'ai un fichier pdf fait avec DBSchéma qui décrit la base avec ses relations

[Pach30]

@escartefigue

Au sujet des guillemets et simple quote , si je mets des guillemets , c'est parce que dans pgAdmin ( en version 3 ou 4 ) , j'ai des erreurs de syntaxe avec de simple quote alors qu'avec des guillemets, ca passe. J'utilise ODBC pour passer mes requêtes , également avec des guillemets . Je remarque même que Pgadmin fait de l'autocomlétion quand je mets des guillemets mais pas dans l'autre cas .
Quelle est alors une différence syntaxique entre les deux formes ?

Merci

[escartefigue]

Les guillemets n'ont d'utilité que si vos noms d'objets sont des noms réservés SQL

Par exemple, je vois qu'il y a une colonne qui s'appelle DAY. DAY est un mot réservé SQL, il faut donc l'encadrer avec les guillemets.
A l'inverse, les autres noms de colonnes et de tables tels que wateringinstructions_watering_activation sont déjà assez compliqués comme ça et n'ont pas besoin de guillemets !

Si vous en avez la possibilité, le plus simple (et de loin) est de s'interdire l'usage de noms réservés comme nom d'objet et de choisir des noms plus courts que wateringinstructions_watering_activation

[Pach30]

Bonjour,
OK, Je vais essayer sans habillage, effectivement pourquoi ne pas se simplifier la vie quand on le peut.
Malheureusement pour les noms de table, je récupère un schéma existant, et je pense que c'est django qui crée des noms aussi alambiqués.
Bonne journée

[ced]

Bonjour,

Attention sur l'habillage avec les guillemets. Il est utile dans deux cas de figures :

1. Utilisation de mots clés pour des noms d'objets (ce qui est déconseillé) ;
2. Sensibilité à la casse des noms d'objets (majuscules - minuscules).

Et dans le deuxième cas (sensibilité à la casse), tout dépend comment ont été créés les objets (tables, colonnes, etc.) à la création de la base de données. Si, comme ça semble être votre cas, ils ont été créés avec des guillemets pour conserver la casse, alors vous allez devoir les conserver.
En effet, d'une manière générale, PostgreSQL n'est pas sensible à la casse pour les objets de la base. Sauf quand on crée les objets avec des guillemets, auquel cas il devient sensible et alors il faut continuer à utiliser les guillemets dans les requêtes pour que les objets soient correctement reconnus.

ced

[Pach30]

Bien vu Ced,

Effectivement mes tentatives de déshabillage se soldent par une erreur SQL 42P01 . Comme les tables ont été créees avec Django , cela voudrait dire que c'est ce framework qui met les guillemets .

[al1_24]

Une preuve de plus que ce n'est pas une bonne idée de laisser l'applicatif (framework ou autre) imposer la structure des données.