L'une des fonctionnalités SQL les plus puissantes est l'opération JOIN, qui fournit un moyen simple et élégant de combiner chaque ligne d'une table avec chaque ligne d'une autre table. Cependant, il peut arriver que nous souhaitions trouver des valeurs d'une table qui ne sont PAS présentes dans une autre table. Comme nous allons le voir dans l'article de blog d'aujourd'hui, les jointures peuvent également être utilisées à cette fin, en incluant un prédicat sur lequel joindre les tables. Connues sous le nom d'anti-jointures, ces jointures peuvent être utiles pour répondre à une variété de questions liées à l'entreprise, telles que :
- Quels sont les clients qui n'ont pas passé de commande ?
- Quels employés n'ont pas été affectés à un service ?
- Quels vendeurs n'ont pas conclu d'affaires cette semaine ?
Ce blog propose une introduction aux différents types d'anti-jointures et à la façon de les écrire en utilisant quelques exemples basés sur la base de données PostgreSQL dvdrental. Nous écrirons et exécuterons les requêtes dans Navicat Premium Lite 17.
La plupart des développeurs et des administrateurs de bases de données connaissent les types de jointures internes, externes, gauches et droites. Bien que ceux-ci puissent être écrits à l'aide d'ANSI SQL, il existe d'autres types de jointures basées sur des opérateurs d'algèbre relationnelle qui n'ont pas de représentation syntaxique dans SQL. Aujourd'hui, nous allons étudier l'un de ces types de jointure : la semi-jointure. La semaine prochaine, nous nous attaquerons à l'anti-jointure similaire. Pour mieux comprendre le fonctionnement de ces types de jointures, nous allons exécuter des requêtes SELECT dans Navicat Premium Lite 17 sur la dvdrental database. Il s'agit d'une base de données gratuite basée sur la base de données d'exemple MySQL Sakila.
Si vous écrivez des requêtes SQL depuis un certain temps, vous connaissez probablement la clause WHERE. Bien qu'elle n'ait aucun effet sur les champs agrégés, il existe un moyen de filtrer les enregistrements en fonction des valeurs agrégées, en utilisant la clause HAVING. Ce blog abordera le fonctionnement de cette clause et fournira quelques exemples de son utilisation dans les requêtes SELECT.
L'opérateur SQL EXISTS nous offre un moyen simple de récupérer des données en fonction de l'existence (ou de la non-existence) d'autres données. Plus précisément, il s'agit d'un opérateur logique qui évalue les résultats d'une sous-requête et renvoie une valeur booléenne indiquant si des lignes ont été renvoyées ou non. Bien que l'opérateur IN puisse être utilisé à peu près dans le même but, il existe quelques différences qu'il convient de connaître. Le blog d'aujourd'hui explique comment utiliser l'opérateur EXISTS à l'aide de quelques exemples et donne des conseils sur les cas où il est préférable d'utiliser EXISTS plutôt que IN.
Au milieu des années 90, Sun Microsystems a lancé un langage que l'on pouvait « écrire une fois, [et] exécuter partout ». Ce langage était, bien sûr, Java. Bien qu'il soit devenu l'un des langages de programmation les plus populaires à ce jour, ce slogan s'est avéré un peu optimiste. L'évolution du langage Java présente de fortes similitudes avec celle de SQL. Il peut lui aussi être porté d'une base de données à une autre, ou même d'un système d'exploitation à un autre, avec peu ou pas de modifications. Du moins, c'est ce que l'on espère. Dans le monde réel, le code de production a tendance à nécessiter quelques ajustements pour fonctionner dans un nouvel environnement. Ce blog présente quelques-unes des raisons pour lesquelles la syntaxe SQL peut différer d'un fournisseur de base de données à l'autre.
- 2024 (1)
- Décembre (1)
- Novembre (1)
- Navicat On-Prem Server : développement de requêtes et collaboration en toute transparence
- Prise en main de Navicat On-Prem Server - Partie 3
- Personnalisation des requêtes à l'aide de la syntaxe propre à Navicat
- Prise en main de Navicat On-Prem Server - Partie 2
- Prise en main de Navicat On-Prem Server - Partie 1
- Octobre (1)
- Septembre (1)
- Août (1)
- Juillet (1)
- Juin (1)
- Mai (1)
- Avril (1)
- Mars (1)
- Février (1)
- Janvier (1)
- 2023 (1)