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.
Une pratique bien établie dans la conception et le développement de bases de données consiste à éviter de stocker des données qui peuvent être calculées ou reconstruites à partir d'autres champs. Par conséquent, il se peut que certaines données manquent lors de la création de vos graphiques dans Navicat BI. Mais ce n'est pas un problème, car Navicat BI fournit des champs calculés spécifiquement à cette fin. Dans le blog d'aujourd'hui, nous allons utiliser les champs calculés pour construire un graphique qui montre les temps de location moyens par client - c'est-à-dire la durée pendant laquelle un client garde un film avant de le rendre. Comme pour la plupart des articles de cette série, les données proviennent de la base de données gratuite « dvdrental ».
Dans Navicat BI, les sources de données font référence à des tables dans vos connexions ou des données dans des fichiers/sources ODBC et peuvent sélectionner des données à partir de tables sur différents types de serveurs. Les champs du jeu de données peuvent être utilisés pour créer un graphique. En fait, lors de la création d'un graphique, vous devrez spécifier la source de données utilisée pour remplir le graphique.
Comme nous l'avons vu tout au long de cette série, les sources de données prennent en charge les types de champs personnalisés. Ceux-ci comprennent : Type-modifié, Concaténé, Mappé, Tri personnalisé et Calculé. Dans le dernier blog, nous avons vu comment utiliser les champs de tri personnalisé pour trier les données d'un graphique en fonction d'un champ de référence. Cette semaine, nous allons apprendre à définir un ordre de tri explicite. Pour ce faire, nous allons créer un graphique à barres verticales pour l'exemple de base de données gratuit « dvdrental » qui affiche la somme des recettes de location de films par mois.
