Journal d'un crafter

samedi 1 janvier 2022

[SQL] SQL Query Order of Execution

Introduction :

L’ordre d’exécution des requêtes SQL est un concept essentiel pour comprendre comment écrire des requêtes sans erreur qui s’exécutent efficacement.

Problème :

Lors de l’écriture de requêtes SQL, nous écrivons généralement les clauses dans cet ordre : SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, puis LIMIT. Cependant, l’ordre dans lequel la base de données interprète la requête est légèrement différent. Cette différence peut entraîner des erreurs ou une inefficacité lors de l’exécution des requêtes.

Voici quelques exemples de mauvaises pratiques liées à l’ordre des opérations SQL qui peuvent ne pas donner le résultat attendu :

Utilisation de HAVING avant GROUP BY : La clause HAVING est utilisée pour filtrer les résultats après l’agrégation des données avec GROUP BY. Si vous utilisez HAVING avant GROUP BY, vous obtiendrez une erreur car HAVING ne peut pas fonctionner sur des données non agrégées. Par exemple :
```
SELECT COUNT(*), department
FROM employees
HAVING COUNT(*) > 5
GROUP BY department;
```
Cette requête générera une erreur car HAVING est utilisé avant GROUP BY.
Utilisation de alias de colonne dans WHERE : Les alias de colonne définis dans SELECT ne sont pas accessibles dans WHERE, car WHERE est exécuté avant SELECT. Par exemple :
```
SELECT salary * 0.9 AS adjusted_salary
FROM employees
WHERE adjusted_salary > 50000;
```
Cette requête générera une erreur car adjusted_salary n’est pas accessible dans WHERE.
Utilisation de LIMIT dans une sous-requête : En SQL standard, LIMIT n’est pas autorisé dans les sous-requêtes. Par exemple :
```
SELECT employee_id, salary
FROM (
    SELECT employee_id, salary
    FROM employees
    ORDER BY salary DESC
    LIMIT 10
) AS top_employees;
```
Cette requête peut générer une erreur dans certains systèmes de gestion de bases de données qui suivent strictement le standard SQL.

Ces exemples illustrent l’importance de comprendre l’ordre d’exécution des opérations SQL pour éviter les erreurs et obtenir les résultats attendus.

Solution :

Pour résoudre ce problème, il est important de comprendre l’ordre d’exécution réel des requêtes SQL:

FROM : La première partie de la requête que la base de données lira est la clause FROM. Ce sont les tables dont nous extrayons les données.
WHERE : La clause WHERE est l’endroit où nous filtrons les lignes de la table.
GROUP BY : La clause GROUP BY est souvent utilisée en conjonction avec des fonctions d’agrégation pour renvoyer une agrégation de résultats regroupés par une ou plusieurs colonnes.
HAVING : La clause HAVING nous permet de filtrer un ensemble de résultats après que les données ont été regroupées et agrégées.
SELECT : L’instruction SELECT est l’endroit où nous définissons les colonnes et les fonctions d’agrégation que nous voulons renvoyer en tant que colonnes sur notre table.
DISTINCT : DISTINCT vient plus tard dans l’ordre des opérations, car il supprime les lignes en double après que toutes les lignes ont été sélectionnées.
UNION : Une union prend deux requêtes qui peuvent toutes deux se tenir seules en tant que requêtes valides et les empile l’une sur l’autre pour se combiner en une seule.

corrections :

Mauvaise pratique : Utilisation de HAVING avant GROUP BY

SELECT COUNT(*), department
FROM employees
HAVING COUNT(*) > 5
GROUP BY department;

Correction : Utilisez HAVING après GROUP BY.

SELECT COUNT(*), department
FROM employees
GROUP BY department
HAVING COUNT(*) > 5;

Mauvaise pratique : Utilisation de alias de colonne dans WHERE

SELECT salary * 0.9 AS adjusted_salary
FROM employees
WHERE adjusted_salary > 50000;

Correction : Utilisez l’alias de colonne dans HAVING ou déplacez le calcul dans WHERE.

SELECT salary * 0.9 AS adjusted_salary
FROM employees
HAVING adjusted_salary > 50000;

-- ou

SELECT salary * 0.9 AS adjusted_salary
FROM employees
WHERE salary * 0.9 > 50000;

Mauvaise pratique : Utilisation de LIMIT dans une sous-requête

SELECT employee_id, salary
FROM (
    SELECT employee_id, salary
    FROM employees
    ORDER BY salary DESC
    LIMIT 10
) AS top_employees;

Correction : Utilisez LIMIT dans la requête principale.

SELECT employee_id, salary
FROM employees
ORDER BY salary DESC
LIMIT 10;

Discussion

Comprendre cet ordre d’exécution peut vous aider à diagnostiquer pourquoi une requête ne s’exécute pas et vous aidera à optimiser vos requêtes pour qu’elles s’exécutent plus rapidement.

Par exemple, parce que la clause FROM vient avant la clause WHERE, vous pouvez filtrer les résultats avec une CTE avant de les joindre dans votre requête finale pour optimiser votre requête.

https://www.sisense.com/blog/sql-query-order-of-operations/

mercredi 29 décembre 2021

[SQL] How to hanlde NULL values in the SELECT statement and convert them to 0?

Introduction

SQL est un langage de programmation de base de données largement utilisé pour stocker, interroger et manipuler des données. Cependant, lors de l’utilisation de SQL, les utilisateurs peuvent rencontrer un problème courant : la présence de valeurs NULL dans les colonnes des bases de données.

Problème

Une valeur NULL est une valeur inconnue ou indéfinie qui peut être présente dans une colonne de base de données. Ces valeurs NULL peuvent causer des problèmes lors de l’exécution de certaines requêtes SQL, car elles peuvent produire des résultats inattendus ou des erreurs. En particulier, les opérations mathématiques et les comparaisons logiques ne peuvent pas être effectuées sur des valeurs NULL, ce qui peut rendre difficile le traitement des données.
Si vous essayez d'effectuer une opération mathématique ou une comparaison logique sur une valeur NULL, le résultat sera également NULL. Cela peut rendre difficile le traitement des données dans certaines situations, en particulier lorsqu'il est nécessaire de faire des calculs sur les données ou de les comparer avec d'autres valeurs.

Solution

Pour résoudre ce problème, SQL fournit la fonction ISNULL. Cette fonction permet de remplacer les valeurs NULL par une valeur par défaut lors de l’exécution d’une requête.

Par exemple, si vous avez une table “orders” avec une colonne “total” contenant le montant total de la commande, vous pouvez utiliser ISNULL pour remplacer les valeurs NULL par 0.

La requête serait alors :

SELECT SUM(ISNULL(total, 0)) AS total_amount FROM orders;

Discussion

En utilisant la fonction ISNULL, vous pouvez manipuler et traiter efficacement les valeurs NULL dans vos requêtes SQL et éviter les erreurs potentielles qui pourraient survenir si vous ne traitez pas correctement ces valeurs.

En résumé, bien que la présence de valeurs NULL en SQL puisse causer des problèmes lors de l’exécution de certaines requêtes SQL, il existe des moyens efficaces pour gérer ces situations et éviter les erreurs potentielles.

https://stackoverflow.com/questions/16840522/replacing-null-with-0-in-a-sql-server-query

mardi 28 décembre 2021

[Postgresql] pg_stat_activity

La table pg_stat_activity de PostgreSQL permet de surveiller les activités en cours dans la base de données. Il est important de surveiller l'état de la transaction dans cette table pour s'assurer que les transactions sont possibles. Si l'état est "idle", il est important de vérifier que le mode manuel de commit est activé pour permettre l'utilisation des transactions.

Voici un tableau comparatif des différents états de la table pg_stat_activity :

État	Signification
active	La session est en train d'exécuter une requête
idle	La session est connectée à la base de données mais n'exécute pas de requête
idle in transaction	La session est en mode manuel de commit et est en train d'exécuter une transaction
idle in transaction (aborted)	La session a été annulée en raison d'une erreur de transaction

Pour passer en mode manuel de commit, il suffit d'exécuter la commande suivante :

sql
BEGIN;

Cette commande active le mode de transaction et permet de valider ou d'annuler les requêtes manuellement. Lorsque le mode manuel de commit est activé, l'état de la transaction dans la table pg_stat_activity passe de "idle" à "idle in transaction".

Exemple pratique : pour s'assurer que les transactions sont possibles, il faut vérifier que l'état de la transaction dans la table pg_stat_activity est "idle in transaction". Si ce n'est pas le cas, il faut activer le mode manuel de commit en exécutant la commande BEGIN.

En résumé, en surveillant attentivement la table pg_stat_activity et en comprenant les différents états de la transaction, il est possible de garantir l'utilisation efficace des transactions dans PostgreSQL.

lundi 26 juillet 2021

Configuring Elastic Common Schema (ECS) & OpenTelemetry for Spring Boot Application

Introduction

Le Elastic Common Schema (ECS) est un standard ouvert qui définit un ensemble commun de champs pour être utilisés lors de l’ingestion de données dans Elasticsearch¹. Il a été conçu pour aider les utilisateurs à normaliser leurs données afin de faciliter leur analyse¹.

Problème

Auparavant, il y avait deux standards séparés pour la structuration des données : le Elastic Common Schema (ECS) et les Conventions Sémantiques OpenTelemetry. Cela pouvait créer des problèmes de compatibilité et rendre plus difficile l’analyse des données provenant de différentes sources¹.

Solution

Elastic et OpenTelemetry ont annoncé une convergence entre le Elastic Common Schema (ECS) et les Conventions Sémantiques OpenTelemetry¹. L’objectif est d’atteindre une convergence de l’ECS et des Conventions Sémantiques OpenTelemetry en un seul schéma ouvert maintenu par OpenTelemetry¹. Cela signifie que les Conventions Sémantiques OpenTelemetry sont véritablement un successeur du Elastic Common Schema¹.

Pour utiliser le ECS dans une application Java Spring, vous pouvez configurer Logback, le logger par défaut pour Spring, pour utiliser le logging Java ECS². Les logs générés de cette manière seront structurés en tant qu’objets JSON et utiliseront des noms de champs conformes à l’ECS².

Discussion

La convergence du ECS et des Conventions Sémantiques OpenTelemetry est une étape importante pour améliorer la convergence de l’observabilité et de la sécurité¹. Cela apporte une grande valeur à la communauté open source car l’ECS a des années de succès prouvés dans les schémas de logs, de métriques, de traces et d’événements de sécurité, offrant une grande couverture des domaines problématiques communs¹.

De plus, la configuration du logging Java ECS dans une application Spring Boot est relativement simple et peut aider à améliorer l’observabilité et la traçabilité de l’application².

https://www.elastic.co/guide/en/ecs-logging/java/current/setup.html

mardi 20 juillet 2021

Spring Cloud Config : How to prevent Spring Config to reset my local git repository to origin/master

git rm origin

[Maven ] Updating Multiple Modules pom.xml -DprocessAllModules=true

http://maven.apache.org/guides/mini/guide-multiple-modules.html

https://stackoverflow.com/questions/28154902/how-to-use-versions-maven-plugin-to-set-child-module-versions

mvn versions:set -DnewVersion=xxx -DprocessAllModules=true

mardi 29 juin 2021

[Java] Enum lookup values by label

L'utilisation des énumérations (enums) pour les valeurs de recherche est une pratique courante en Java, et pour de bonnes raisons. Dans cet article, nous allons discuter des avantages de cette pratique et expliquer comment elle peut améliorer la lisibilité, la sécurité et la maintenabilité de votre code.

Lisibilité améliorée

Lorsque vous utilisez des énumérations pour définir des valeurs de recherche, vous donnez à votre code une signification claire et facilement compréhensible. Par exemple, au lieu de définir une chaîne de caractères telle que "M" pour représenter un mois, vous pouvez utiliser une énumération telle que "Janvier", "Février", etc. Cela rend votre code plus lisible et plus facile à comprendre pour les autres développeurs qui peuvent travailler sur votre code.

Sécurité renforcée

Les énumérations offrent également une sécurité supplémentaire à votre code. En effet, elles garantissent que seules les valeurs prédéfinies peuvent être utilisées pour une recherche donnée. Cela évite les erreurs de saisie ou les valeurs incorrectes, qui peuvent entraîner des résultats inattendus ou des exceptions lors de l'exécution. Les énumérations sont également plus sûres que les chaînes de caractères, qui peuvent facilement être modifiées ou corrompues.

Maintenabilité améliorée

En utilisant des énumérations pour les valeurs de recherche, vous pouvez également améliorer la maintenabilité de votre code. Si vous devez modifier une valeur de recherche, vous n'aurez qu'à le faire dans une seule classe, plutôt que de rechercher et de remplacer cette valeur dans plusieurs endroits du code. Cela rend les modifications plus rapides et moins risquées, car vous n'avez pas besoin de vous soucier des effets de bord ou des modifications involontaires dans d'autres parties du code.

Exemple de code

Voici un exemple de code qui utilise une énumération pour les valeurs de recherche :

public enum SortOrder {

    ASC("asc"),
    DESC("desc");

    private static final HashMap<String, SortOrder> MAP = new HashMap<String, SortOrder>();

    private String value;

    private SortOrder(String value) {
        this.value = value;
    }

    public String getValue() {
        return this.value;
    }

    public static SortOrder getByName(String name) {
        return MAP.get(name);
    }

    static {
        for (SortOrder field : SortOrder.values()) {
            MAP.put(field.getValue(), field);
        }
    }
}

After that, just call:

SortOrder asc = SortOrder.getByName("asc");

https://www.baeldung.com/java-enum-values#caching