DBA et développeur, cet article est pour vous… y’en faut pour tous les goûts comme on dit. Voici deux outils peu utilisés dans les bases de données que j’ai pu voir récemment. Et pourtant, ils permettent de simplifier votre script sql et de le rendre plus lisible et plus structuré (génial lol).

Les constantes en SQL

Ce n’est pas révolutionnaire mais si vous ne le savez pa déjà, vous pouvez définir un groupe de constante en sql avec la clause “WITH … AS”. Cela vous permettra d’utiliser ces données fixes comme des tables pratiquement.

Par exemple si on définit les constantes de temps :

WITH timeconstants AS (
SELECT 60 as seconds,
       60 as minutes,
       24 as hours,
       365 as days,
       7 as week,
       ['Lundi','Mardi','Mercredi','Jeudi','Vendredi','Samedi','Dimanche'] as daysweek,
),

C’est pas mal mais comment utiliser ces constantes ? comme une requête.

SELECT seconds, minutes, hours, days FROM timeconstants;

Enfantin comme dirait l’autre.

Les noms de résultats

Je parlerai plutôt d’alias mais souvent en sql on parle d’alias pour les alias de table par exemple et on l’utilise plutôt dans la clause FROM. En totu cas le principe est presque el même sauf qu’il s’agit à la manière d’un vue d’attribuer un alias à une requête entière.

On le fait ainsi :

myextract AS (
   SELECT
   IF(colonne1 < 10, "little", "big") AS qualified_sale,
   colonne1,   nb_hours,   colonne2 / 10  FROM mytable)

Et si on combine les deux on retrouve des trucs du genre :

SELECT nb_hours * minutes * secondes AS timer
FROM mytable, timeconstants;

Alors je fais un peu n’importe quoi mais c’est un exemple.Ici on utilise les constantes minutes et secondes pour calculer les heures passées en secondes.

L’intérêt vous le voyez c’est que désormais tout possède un nom et que pour appeler les éléments ils doivent être définis à travers le “FROM”. Derrière il est beaucoup plus simple de faire de la modélisation et surtout si vos constantes évoluent vous n’avez pas besoin de revoir toutes vos requêtes.

Pour ces éléments SQL que nous venons de voir, on parle de CTE dans le jargon DBA. CTE pour Common Table Expression. Ces petites clauses permettent de jouer sur les “alias” pour créer des pseudos tables qui ne sont pas non plus des vues et qui visent à simplifier le travail de maintenance.

L’article [SQL] : créez des constantes et des noms de résultats est apparu en premier sur Xavki.

Vous utilisez postgresql, cet article est pour vous ? Encore une fois rien de bien compliqué mais de l’élémentaire et efficace. Si vous faites souvent des imports de base sans reprendre tous les GRANT (droits) qui vont bien, vous vous retrouvez à faire des ALTER sur les tables pour redonner les bons droits aux bons users (utilisateurs).

Mais pour les séquences ça peut se compliquer car vous n’avez pas de possibilité de faire cela en masse comme on peut faire un “GRANT ALL ON ALL TABLES”. Du coup on va quand même pas se palucher les droits à la main non ? et pis quoi encore lol.

Bon les DBA postgresql le savent il suffit de faire une petite boucle qui va bien comme ceci :
echo "select sequence_name FROM information_schema.sequences" | psql --cluster 9.4/main -d madatabase | grep -v '('|awk '{print "GRANT ALL ON TABLE madatabase."$1" TO monuser;"}' > maj_grant_monuser.sql

Pas trop compliqué :

• On liste les séquences de la base
• on vire la ligne vide
• on édite une line GRANT sur la séquence
• on ajoute cette ligne dans un fichier sql

Il vous reste ensuite à lancer ce script et le tour est joué. Dans mon cas, j’ai indiqué –cluster pour le cas où on a plusieurs cluster sur la machine sinon viré l’option et l’argument.

Photo by rawpixel.com on Pexels.com

L’article [Postgresql] : Appliquer un GRANT à toutes les séquences d’une base est apparu en premier sur Xavki.

Les imports de bases se passent plus ou moins comme l’on veut. Par exemple, si on restaure des datas dans une base différente ou si on créé la base morceau par morceau (structure, user…), vous pouvez vous retrouver avec les tables de votre applis situées dans le schéma “public”. Pas forcément ce que l’on recherche. Bien souvent on créé un schéma spécifique pour chaque application.

Comment réaffecter toutes les tables du schéma “public” dans un autre schéma ?

Pas très compliqué, pour une table :

ALTER TABLE public.nommatable SET SCHEMA monschema;


Pour une seule table pas de problème. Mais pour toutes les tables ?

DO
$$
DECLARE
	row record;
BEGIN
	FOR row IN SELECT tablename FROM pg_tables WHERE schemaname = 'public' -- and other conditions, if needed
	LOOP
		EXECUTE 'ALTER TABLE public.' || quote_ident(row.tablename) || ' SET SCHEMA monschema;';
	END LOOP;
END;
$$;

Photo by Anthony on Pexels.com

Cette fonction/procédure permet donc de lister toutes les tables puis de lancer une boucle sur celle-ci en faisant le ALTER TABLE SET SCHEMA.

L’article [Postgresql] : changer des tables de schéma est apparu en premier sur Xavki.