Conseils requête SQL

Bonjour à toutes et à tous.
Windows 10; PostgreSQL 16.
Soient 2 tables table_1 (50 enregistrements) et table_2 (20 enregistrements).
Table_1 possède une colonne 'suivi' de type booléen et, entre autres, une colonnes 'isin' de type 'caracter' de longueur 32.
J'aimerais copier les éléments de la colonne 'isin' de la table_1 dont la colonne de type booléen a une valeur true, dans la table_2.
Je peux utiliser une méthode de bourrin et faire manuellement cette copie, mais j'aimerais automatiser le processus par requête SQL.
Pour que vous puissiez m'aider je peux essayer d'être plus précis dans la description de mon problème.
En vous remerciant d'avance pour votre aide.

Michel.

Bonjour,

Là, pour vous aider, il nous faut le schéma des tables, un exemple sur les données, le lien éventuel entre les deux tables et un exemple du résultat que vous voulez obtenir...
En l'état, je comprends que vous voulez faire entrer une chaîne de caractères dans un booléen, ce qui n'est juste pas possible, le tout sans connaître le lien entre les lignes de la première table à mettre à jour avec les lignes de la deuxième table...

ced

Bonjour

@Ced : si je comprends bien, il ne s'agit pas de recopier la colonne de type booléen dans le type char, mais de recopier le code ISIN de T1 dans T2 si le booléen de T1 est à "true".

Mais, à de très rares exceptions près, recopier une valeur dans une autre table est une redondance qu'il ne faut pas faire.
Donc, @Miflon, précisez pourquoi vous voulez créer cette redondance : quel est le besoin fonctionnellement parlant ?

Ensuite, communiquez le description exacte de vos tables (script DDL contenant les ordres CREATE TABLE), un extrait de leur contenu ainsi qu'un exemple de résultat attendu.

Je programme au moyen de Lazarus, en amateur.
Pourquoi?
Je désire, pour une gestion de mon compte boursier, aller chercher sur le site d'Euronext les cours d'un certain nombre d'actions pour réaliser des moyennes, des droites de tendances etc. Je sais faire cette collecte de données que je veux automatiser en fin de journée.
Comment?
J'ai une table regroupant la liste des actions que je possède.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

-- Table: s_ent.t_e_action_act   -- DROP TABLE IF EXISTS s_ent.t_e_action_act;   CREATE TABLE IF NOT EXISTS s_ent.t_e_action_act ( act_id integer NOT NULL DEFAULT nextval('s_ent.t_e_action_act_act_id_seq'::regclass), tax_id s_ent.d_n_cle_etrangere NOT NULL, elg_id s_ent.d_n_cle_etrangere NOT NULL, pla_id s_ent.d_n_cle_etrangere, mar_id s_ent.d_n_cle_etrangere, ind_id s_ent.d_n_cle_etrangere, srd_id s_ent.d_n_cle_etrangere, act_valeur s_ent.d_a_texte_64 COLLATE pg_catalog."default", act_isin s_ent.d_a_texte_32 COLLATE pg_catalog."default", act_suivi boolean, CONSTRAINT t_e_action_act_pkey PRIMARY KEY (act_id) )   TABLESPACE pg_default;   ALTER TABLE IF EXISTS s_ent.t_e_action_act OWNER to postgres;

---

J'ai envisagé de créer une table regroupant les ISIN des actions que je suis actuellement avec la possibilité d'en rajouter par la suite, ça je sais faire.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

-- Table: s_ent.t_e_cours_crs   -- DROP TABLE IF EXISTS s_ent.t_e_cours_crs;   CREATE TABLE IF NOT EXISTS s_ent.t_e_cours_crs ( crs_id bigint NOT NULL DEFAULT nextval('s_ent.t_e_cours_crs_crs_id_seq'::regclass), crs_isin character(32) COLLATE pg_catalog."default", crs_date date, crs_cours money, CONSTRAINT t_e_cours_crs_pkey PRIMARY KEY (crs_id), CONSTRAINT t_e_cours_crs_crs_isin_key UNIQUE (crs_isin) )   TABLESPACE pg_default;   ALTER TABLE IF EXISTS s_ent.t_e_cours_crs OWNER to postgres;

---

Et ensuite mettre le contenu de la colonne crs_isin dans une boucle dans Lazarus pour récupérer le cours souhaité et peupler s_ent.t_e_cours_crs. Je compte réaliser cette collecte sur les 6 mois précédents ce qui fait 6(mois)*4(semaines)*5(jours)*15(actions) = 1800 lignes, que je ne désire pas inclure dans la table s_ent.t_e_action_act. D'où la création de la table s_ent.t_e_cours_crs. Ma question concerne le peuplement "élégant" de cette dernière table que je peux bien sûr peupler manuellement en ce qui concerne la ligne crs_isin d'où le terme de bourrin utilisé précédemment.
Vous savez tout et vous remercie par avance pour votre patience et votre aide.
Michel.

Bonjour,

Il faut donc stocker dans la deuxième table tous les code ISIN de la première dont le booléen est à "true".

Pourquoi définir un ISIN de 32 caractères alors que c'est un code normé sur 12 caractères ? J'ai corrigé en char(12) dans mon script (du varchar est contre-performant pour de petites tailles comme celle-ci).

Également, pourquoi définir l'identifiant de la deuxième table en bigint alors que c'est de l'integer dans la première et que la deuxième contient un sous-ensemble de la première (seules les lignes dont le booléen est à "true"). C'est un détail, mais autant économiser de la place et définir cet identifiant en integer.

Aussi, puisque la table 2 est un sous-ensemble de la table 1, il faut conserver la valeur d'identifiant de T1 dans T2 pour pouvoir réaliser les jointures.

Et enfin, dans la première table, il y a une pléthore de clefs étrangères, souvent symptomatique d'une mauvaise modélisation (le modèle conceptuel de données permettrait de s'en assurer), et aucune de ces colonnes suffixées _clef_etrangère ne fait l'objet de contrainte foreign key : c'est une grave erreur qui compromet l'intégrité de la base de données.

Voici un script avec des tables simplifiées aux colonnes qui nous intéressent et qui donne le résultat attendu tel que je l'ai compris :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

drop table if exists t_e_action_act ; drop table if exists t_e_cours_crs ; CREATE TABLE t_e_action_act ( act_id integer generated by default as identity primary key , act_isin char(12) NOT NULL , act_suivi boolean ) ; CREATE TABLE t_e_cours_crs ( crs_id integer primary key , crs_isin char(12) NOT NULL unique ) ; insert into t_e_action_act (act_isin, act_suivi) values ('00000000001', true) , ('00000000002', false) , ('ABCDEF00000', false) , ('ABABABABABAB', true) , ('TOTO_ET_TITI', true) ; insert into t_e_cours_crs (crs_id, crs_isin) select act_id , act_isin from t_e_action_act where act_suivi is true ;

---

Cela étant dit, je pense que la deuxième table n'a pas d'intérêt

Merci escartefigue pour tes remarques.
Correction pour la dimension de ISIN dans les deux table effectuée.
Correction de crs_id en int effectuée.

Citation:

---

il faut conserver la valeur d'identifiant de T1 dans T2 pour pouvoir réaliser les jointures.

---

Précédemment j'avais testé la jointure après avoir peuplé manuellement la table t_e_cours_crs

Code:

---

1 2 3 4 5

SELECT act_valeur, crs_isin FROM s_ent.t_e_action_act JOIN s_ent.t_e_cours_crs ON act_isin = crs_isin ORDER BY act_valeur;

---

et elle donnait le bon résultat.
Je n'ai pas encore corrigé la structure de t_e_action_act en ce qui concerne les clés étrangères. Toutes ces clés étrangères sollicitent des tables de référence dans le schéma s_ref qui concernent :

• les taxes appliquées dans la transaction,
• l'éligibilité au PEA ou PEA-PME,
• la place financière,
• la place de cotation,
• le marché,
• l'indice auquel appartient l'action,
• l'éligibilité de l'action au SRD.

Citation:

---

je pense que la deuxième table n'a pas d'intérêt

---

Comment faire alors pour stocker les 1800 cours (environ) et leur date sans créer cette table. De plus je risque de changer la période de collecte de ces valeurs en passant à une période d'un an, voire plus.
Au vu de ta réponse je vais reprendre l'étude de la cohérence des types de données de la base. Je sais bien qu'il faut faire un tableau des types de données pour définir les domaines de définition des valeurs mais ...
Merci escartefigue pour ta réponse.

Oulala voila quelqu'un qui suit ma norme de nommage à la lettre !!!

A +

Citation:

---

Envoyé par Miflon

Toutes ces clés étrangères sollicitent des tables de référence dans le schéma s_ref qui concernent :

• les taxes appliquées dans la transaction,
• l'éligibilité au PEA ou PEA-PME,
• la place financière,
• la place de cotation,
• le marché,
• l'indice auquel appartient l'action,
• l'éligibilité de l'action au SRD.

---

OK, mais si ces FK ont un intérêt avéré, il faut alors d'une part créer les tables de référence si ce n'est déjà fait et d'autre part ajouter les contraintes foreign key pour garantir l'intégrité de la base.
Il est fortement recommandé de modéliser en commençant par le modèle conceptuel et non pas par les tables et en utilisant un logiciel adhoc, comme l'excellent Looping que vous pouvez télécharger gratuitement ICI.
Avec un logiciel de modélisation, la cohérence des type de données et les contraintes d'intégrité sont générées automatiquement.

Citation:

---

Envoyé par Miflon

Comment faire alors pour stocker les 1800 cours (environ) et leur date sans créer cette table. De plus je risque de changer la période de collecte de ces valeurs en passant à une période d'un an, voire plus.

---

Le cours d'un titre n'a de sens qu'à une date. Au niveau conceptuel, le MCD, on établira donc une association (quoter) entre l'entité-type [TITRE] et une entité-type [CALENDRIER]. La table "quoter" issue de cette association aura donc pour clef l'identifiant du titre et la date.

MCD :
[TI_TITRE] 0, n --- (QU_quoter) --- 0,n [CA_CALENDRIER]

MLD :

• TI_TITRE (TI_ident, TI_isin, TI_libelle....)
• CA_CALEND (CA_date) <== cette table n'a pas besoin d'être générée, dans looping, on cochera la case "entité-type fictive"
• QU_QUOTER(TI_ident, CA_date, QU_valeur)

@ SQLPro Quand on est amateur il faut toujours s'inspirer des pros.
@ escartefigue Les tables du schéma s_ref sont indispensables car elles me permettent de sauvegarder les transaction, les coupons ... à partir de fiches dont les données sont présentées de manière compréhensible dans Lazarus avec des TDBLookUpComboBox ... .
Mon "travail" étant effectué de manière morcelée, la base de données initiale est construites petit à petit, ce qui est un handicap pour la cohérence. Je parts en "Looping" bientôt :D.

@ escartefigue
J'ai changé la requête de peuplement de la table s_ent.t_e_cours_crs que tu m'as proposée. Car la colonne crs_id se chargeait avec les valeurs de act_id. La requête suivante me donne satisfaction.

Code:

---

1 2 3 4

INSERT INTO s_ent.t_e_cours_crs (crs_isin) SELECT act_isin FROM s_ent.t_e_action_act WHERE act_suivi is true;

---

Il me reste la collecte des données sur Euronext à mettre en oeuvre.
Bonne journée, Michel.