Discussion :

[Eris Stig]

Bonjour,

Je travaille depuis peu sur un environnement Php PostrgresSQL, via phpPgAdmin, j’étais sur un autre SGBD avant avec très peu de requêtes SQL puisque presque tout était automatisé.

Je souhaiterai créer un script qui permette d’insérer des données dans la colonne Infos de chacune des tables ci dessous, pour éviter d’avoir à le faire sur tous les PC à la main :



J’hésite entre trois requêtes, je n’ai pas le niveau nécessaire pour savoir laquelle est la plus adaptée à ma situation, ni comment mon script va être inséré par mes collègues,

Code :

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

1
2
3
ALTER TABLE A ALTER COLUMN Information 
 
SET 'Informations concernant la Table A'

et répéter pour toutes les tables ?

ou

Code :

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

INSERT INTO A (Information) VALUES (info A, info B, info C, info D)

bon celui là je sais que c'est faux puisqu'il faudrait dire insert into A, B, C, D ? je ne sais pas comment faire sur plusieurs tables, ou alors répéter pour chacune ?

ou

Code :

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

UPDATE A SET Information (info A, info B, info C, info D)

Je suis actuellement en formation en alternance et j'aimerai vraiment réussir ce script, mais comme je débute, j'ai un peu besoin d'aide ^^"
Mon collègue m'a orienté en me parlant d'ALTER TABLE, mais en SQL il me semblait que c'était pour modifier le type d'une colonne d'une table et non pour y ajouter des données...

En vous Souhaitant un bon weekend,

Éris.

[al1_24]

Code :

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

1
2
ALTER TABLE A ALTER COLUMN Information 
SET 'Informations concernant la Table A'

et répéter pour toutes les tables ?

La commande ALTER TABLE ne sert pas à ajouter ou modifier des lignes mais à modifier la structure de la table (dont ajouter ou supprimer des colonnes) ou les contraintes qui lui sont associées.

Code :

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

INSERT INTO A (Information) VALUES (info A, info B, info C, info D)

bon celui là je sais que c'est faux puisqu'il faudrait dire insert into A, B, C, D ? je ne sais pas comment faire sur plusieurs tables, ou alors répéter pour chacune ?

En effet, il faut une commande par table.

Code :

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

UPDATE A SET Information (info A, info B, info C, info D)

La commande UPDATE comme la commande INSERT n'opère que sur une seule table à la fois.
Il faut faire attention en plus avec la commande UPDATE que celle-ci s'exécutera sur toutes les lignes de la table à moins d'ajouter une restriction avec la clause WHERE.

[Eris Stig]

Du coup la meilleure solution serait de faire un

Code :

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

INSERT INTO A (Information) VALUES 'info A'

Puis la même chose pour B et enfin pour C et D ?

[al1_24]

La syntaxe correcte serait :

Code :

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

INSERT INTO A (Information) VALUES ('info A')

Cette commande va ajouter une nouvelle ligne dans la table A en y renseignant uniquement la colonne Information donc en laissant toutes les autres colonnes vides (à l'exception d'un éventuel identifiant auto-incrémenté).
Est-ce bien ce que tu souhaites faire ?

[Eris Stig]

Hum non pas vraiment. Il s'agit là des tables de ma BDD, donc je dois renseigner le champ Information sans ajouter de lignes dans ce tableau. Si on clique sur A, on obtient le contenu de la table A avec plusieurs champs également dont une autre colonne information appelée Commentaire que je dois également remplir.

Mon but est de remplir cette colonne sans toucher à la structure actuelle ou aux autres données des tables :/

[al1_24]

C'est donc la commande UPDATE qu'il faut utiliser en précisant bien la ligne qui doit être mise à jour (identifiant unique ou clé primaire).

[Eris Stig]

Très bien merci beaucoup ! Je vais essayer de rédiger tout ça lundi au bureau passez un bon dimanche, encore merci pour votre aide !

[Eris Stig]

Bonjour,
j'ai donc rédigé la requête SQL suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
UPDATE A 
SET Commentaire = ‘Données relatives à A‘
 
UPDATE B 
SET Commentaire = ‘Données relatives à B'
 
UPDATE C
SET Commentaire = ‘Données relatives à C'
 
UPDATE D 
SET Commentaire = ‘Données relatives à D'

(il s'agissait de commentaire et non d'information)

Ma question est la suivante : Dans phppgadmin, je séléctionne ma base de données concernée, puis je clique sur le schéma 'public'. J'ai alors l'apperçu de toutes mes tables, qui contiennent des données du type libelle, code adresse, etc.
comme on peut le voir ci dessous :



Ma requête rédigée ci dessus ne va-t-elle pas renseigner la colonne Commentaire à l'intérieur des tables A, B, C et D ?
Au lieu de renseigner le commentaire des tables ?

La solution ne serait elle pas :

Code :

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

1
2
3
UPDATE public  
SET Commentaire = ‘Données relatives à un actif‘
WHERE Table = ao_actif

Merci pour votre aide,
Eris

[escartefigue]

Bonjour

Non : l'ordre UPDATE doit se rapporter à une table ou une vue et de préférence à une vue, mais pas à un schéma !

Par ailleurs, vos tables sont très mal modélisées :

• le type TEXT pour les adresses est contre-performant et inadapté. Les adresses sont normées : en France, c'est 6 lignes de 38 caractères. Cf. la norme de la poste. Si vous avez des adresses à l'étranger, référez-vous aux normes en vigueur dans les pays concernés ou utilisez du varchar suffisamment long (50 par exemple) plutôt que du TEXT
• le code postal, pour les adresses françaises, c'est char(5), là encore, du varchar est inutile et pénalise les perfs. Si vous avez des adresses étrangères, utilisez la longueur maxi d'un CP en conservant du char plutôt que du varchar ou pire, du text
• la ville n'a rien à faire dans la table des adresses, il devrait y avoir une FK dans cette table pointant sur la table des villes
• le pays n'a rien à faire dans la table des adresses, il devrait y avoir une FK dans la table des villes pointant sur la table des pays

[Eris Stig]

Ah d'accord très bien,
Alors ce n'est pas moi qui ai créé la Base de données, et ce n’est pas encore à moi d’optimiser le fonctionnement de la base de données sur ce point là. Mais je note au cas où on en parlerait merci.
Je suis actuellement en alternance développeuse d'application PHP depuis 2 semaines, ce qui explique que j'ai encore besoin d'aide.
Comment faire dans ce cas pour modifier les colonnes Commentaire des schémas, ou à l’intérieur des tables*? C’est toujours du langage SQL*?
Sur internet j’ai pu trouver la piste de

Code :

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

COMMENT ON { …} IS ‘texte’

est ce que ce serait la solution*?

[Eris Stig]

Donc, j’ai demandé à un collègue qui est mentor de ma formation, ça n’est pas du SQL donc je ne risquait pas de trouver toute seule, j’avais trouvé dans la doc sur la commande COMMENT, et en effet il faut*écrire*:

Code :

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

COMMENT ON TABLE A IS ‘commentaire de la table A’*;

à écrire dans le script php Storm.
J’espère que ça en aidera d’autres, et merci de répondre à la question ou ne pas répondre du tout la prochaine fois. Merci pour l'aide,
Eris

[escartefigue]

Excusez-moi, j'avais mal compris la question initiale
COMMENT ON sur une table ou une colonne est un ordre SQL de type "DDL" (Data Definition Language), rien à voir avec un ordre UPDATEqui lui est de l'ordre du DML (Data Manipulation Language)

Le DML modifie le contenu des tables (je pensais que le commentaire dont vous parliez était un contenu : qu'il s'agissait d'une colonne )
Le DDL modifie la structure des objets base de données et les commentaires liés à ces objets (et notamment les COMMENTS et REMARKS)

Par contre, votre "mentor" se trompe : DML et DDL sont des sous-parties du SQL, il y en a d'autres (ex : le TCL Transaction Control Langage)

[Eris Stig]

Oui mon mentor n'a pas dit qu'il ne s'agissait pas de SQL, je voulais dire "ça n'est pas du SQL Standard, là où je situe mes connaissances.
N'ayant pas encore fait de SQL DDL mais uniquement les requêtes standard, la question sortait de mon domaine de compétences et je ne voulais pas faire d'erreur en tentant de résoudre le problème seule.
Je vais donc aller chercher des cours me permettant de connaitre également ces commandes ci puisque je suis amenée à évoluer vers cette sous partie du langage SQL.

Encore merci, bonne journée,
Eris Stig.

[escartefigue]

La génération du script DDL est grandement facilitée par l'utilisation d'un logiciel de modélisation : la plupart des logiciels produisent le DDL avec les ordres CREATE TABLE, CREATE INDEX... et certains d'entre eux vont jusqu'à l'ajout des commentaires et remarques.

[SQLpro]

Oui mon mentor n'a pas dit qu'il ne s'agissait pas de SQL, je voulais dire "ça n'est pas du SQL Standard, là où je situe mes connaissances.
N'ayant pas encore fait de SQL DDL mais uniquement les requêtes standard, la question sortait de mon domaine de compétences et je ne voulais pas faire d'erreur en tentant de résoudre le problème seule.
Je vais donc aller chercher des cours me permettant de connaitre également ces commandes ci puisque je suis amenée à évoluer vers cette sous partie du langage SQL.

Encore merci, bonne journée,
Eris Stig.

le DDL, le DML, le DCL et le TCL font tous partie du langage normalisé SQL donc du standard…

• DDL = Data Definition Language. En français LDD pour Langage de Définition des Données => CREATE …, ALTER …, DROP… (pour l'essentiel)
• DML = Data Manipulation Language. En français LMD pour Langage de Manipulation des Données => INSERT …, UPDATE …, DELETE …, MERGE …, TRUNCATE… (pour l'essentiel)
• DCL = Data Control Language. En français LCD pour Langage de Contrôle des Données => GRANT …, REVOKE … (pour l'essentiel)
• TCL = Transaction Control Language. En français LCT pour Langage de Contrôle des Transaction => BEGIN WORK/TRANSACTION …, COMMIT, ROLLBACK (pour l'essentiel)

Pour apprendre le SQL, mon livre :


A +

[MaximeCh]

du varchar ... pénalise les perfs

Ce point précis est faux pour postgres. Le seul type de caractère qui ait une décote de performances est le type char, je vous renvoie à la documentation :
https://www.postgresql.org/docs/12/d...character.html
Il y est dit le contraire, le seul type texte qui peut entraîner une baisse de performances, stockage ou cycles CPU, est le type char(n).

L'usage de text est conseillé pour du texte de longueur variable, sinon char(n).

[escartefigue]

Je maintiens mes propos : pour des petites longueurs, du char est préférable et ce malgré le remplissage à blanc des octets inutilisés

L'article cité oublie un peu vite que le varchar provoque des déplacements de pages data et index lors des update. Il oublie également le besoin de réaligner sur une longueur fixe pour les opérations de tri ou de regroupement.

[MaximeCh]

L'article cité oublie un peu vite que le varchar provoque des déplacements de pages data et index lors des update. Il oublie également le besoin de réaligner sur une longueur fixe pour les opérations de tri ou de regroupement.

On peut critiquer le manque de précision de la doc postgres parfois, mais, étant écrite par les développeurs eux-mêmes, je ne l'ai jamais prise en défaut.

Avec le moteur de stockage séculaire et MVCC, il n'y a pas de déplacement de page lors d'un update, c'est du copy-on-write, s'il y a déplacement ça intervient lors du vacuum, pour les longueurs fixes comme variable. Ce problème arrivera avec zheap/zedstore, le nouveau moteur de stockage colonne.

[escartefigue]

Le déplacement de pages est intrinsèque au changement de longueur, je prends un exemple

Soit une page de 4k et des lignes de longueur moyenne de 0,1k, je peux en théorie ranger 40 lignes par page (dans les faits un peu moins à cause des octets de service, mais peu importe)
Si la page est pleine et que je modifie la longueur d'une des colonnes varchar pour la passer de 5 à 25 caractères, alors la ligne ne tient plus dans la page, il faut donc l'écrire dans une autre page.
il faut également modifier l'adressage des index vers cette page.
On génère donc des I/O inutiles et on amplifie la désorganisation avec cette colonne varchar, phénomène qui ne se produit pas avec une colonne de type char

Varchar, c'est bien, si la longueur effective d'une même colonne sur différentes lignes est différente, mais qu'elle change peu pour une même ligne, donc s'il y a peu d'update.

[MaximeCh]

Ce n'est pas comme ça que fonctionne postgres. Ca fonctionne avec le principe copy-on-write, CoW, qu'on retrouve dans d'autres SGBD, systèmes de fichiers...
A chaque mise à jour d'une ligne, une nouvelle ligne est systématiquement créée. L'ancienne ligne est supprimée de la carte de visibilité, mais pas de la table elle même.

Un vacuum simple ira rendre de nouveau disponible l'ancienne ligne pour de nouvelles écritures. Un vacuum full ira faire ce que windows fait avec la défragmentation, c'est à dire une coûteuse réécriture complète avec réorganisation de la table.

Dans tous les cas donc l’adressage de l'index est mis à jour lors d'un update.