Les requêtes SQL pour interroger la Bdd peuvent être très gourmandes en ressources système et en temps processeur. Alors autant les formuler correctement afin de ne pas surcharger le serveur et donc d'afficher les résultats rapidement. Vous pensez connaître la fonction "SELECT", la plus simple et la plus utilisée ? Bien, alors examinons cela...

Syntaxe d'extraction des données

Il est plus performant de définir les requêtes de sélection dans la propriété Source d'un objet de formulaire ou d'état au lieu de les stocker séparément dans la bdd. De même il est performant de créer les requêtes dynamiquement dans des procédures ou des fonctions VBA. Il faut savoir que la syntaxe présente des différences dans ces deux cas de figure.

Un prédicat spécifie les enregistrements qui vont être sélectionnés

ALL

DISTINCT

Si on omet DISTINCT, cette requête renvoie les deux enregistrements Barthez. Si la clause SELECT contient plusieurs rubriques, la combinaison des valeurs de toutes ces rubriques doit être unique, pour un enregistrement donné, pour que ces valeurs apparaissent dans le résultat. Le résultat d'une requête qui utilise DISTINCT ne peut pas être mis à jour et ne reflète pas les modifications ultérieures effectuées par d'autres utilisateurs.

DISTINCTROW

SELECT DISTINCTROW Société FROM Clients INNER JOIN Commandes ON Clients.[CodeClient] = Commandes.[CodeClient] ORDER BY Société;

Si on omet DISTINCTROW, cette requête produit plusieurs lignes pour chaque société ayant passé plusieurs commandes. DISTINCTROW n'a d'effet que si vous sélectionnez des rubriques dans seulement quelques-unes des tables utilisées dans la requête. DISTINCTROW est ignoré si votre requête n'inclut qu'une seule table ou si vous sélectionnez les rubriques de toutes les tables.

Remarque:
La clause FROM nomTableMaîtresse INNER JOIN nomTableSecondaire ON rubriqueTableMaîtresse OPERATEUR rubriqueTableSecondaire permet de spécifier le type de jointure (équi-jointure) et le sens de la liaison entre les deux tables.

TOP n [PERCENT]

Si vous n'incluez pas la clause ORDER BY, la requête renverra une série de 10 enregistrements choisis arbitrairement parmi ceux de la table Etudiants qui remplissent les conditions de la clause WHERE. Le prédicat TOP n'effectue pas de choix entre des valeurs égales. Dans l'exemple précédent, si, parmi les meilleurs résultats obtenus, le dixième et le onzième ont obtenu la même moyenne, la requête renvoie 11 enregistrements. Vous pouvez également utiliser le mot réservé PERCENT pour renvoyer un certain pourcentage des premiers ou derniers enregistrements d'une plage spécifiée par la clause ORDER BY. Supposons qu'au lieu des 10 meilleurs étudiants, vous souhaitiez sélectionner 10 pour cent de la promotion:

SELECT TOP 10 PERCENT Nom, Prénom FROM Etudiants WHERE Promotion = 2001 ORDER BY Moyenne DESC;

La clause WHERE

Les conditions de recherche peuvent faire référence à des rubriques qui ne sont pas incluses dans la liste de sélection. Elle est très utilisée pour définir des jointures:

renverra le nom des clients ayant des factures, ainsi que la/les date des factures correspondantes. Il est important de faire une jointure sur CodeClient dans la clause Where, pour indiquer au moteur SQL que la liaison entre les deux tables s'effectue sur cette colonne "commune".

Les agrégats

Les fonctions d'agrégats calculent des valeurs à partir des données d'une colonne particulière. Les opérateurs d'agrégat sont : sum (somme), avg (moyenne), max (le plus grand), min (le plus petit), et count (le nombre d'enregistrements retournés).

Si on doit comparer des littéraux dates, il faudra les spécifier en format américain et les encadrer avec le signe #.

Si on doit comparer des valeurs non numériques, il faudra les encadrer avec le signe '

La clause GROUP BY

Cette clause, utilisée dans une instruction SELECT, divise le résultat d'une requête en groupes. Actuellement le regroupement peut s'effectuer sur un maximum de 10 rubriques. La clause GROUP BY est présente dans les requêtes qui comportent également des fonctions d'agrégats, ces dernières produisant alors une valeur de synthèse pour chaque groupe, appelée parfois agrégat vectoriel.

La clause HAVING

Cette clause permet de limiter les enregistrements regroupés par la clause GROUP BY. Le moteur de la Bdd traite une requête comportant les clauses WHERE, GROUP BY et HAVING comme suit:

1. Tout d'abord il élimine les lignes qui ne satisfont pas la clause WHERE.
2. Il calcule et forme les groupes selon les spécifications de la clause GROUP BY
3. Il élimine tous les groupes qui ne satisfont pas la clause HAVING

Une clause HAVING peut contenir jusqu'à 40 expressions liées par des opérateurs logiques comme AND et OR.

Trie, par ordre croissant ou décroissant, les enregistrements résultants d'une requête en fonction de la ou des rubriques spécifiées. Une rubrique de type Mémo ou OLE ne peut pas être triée. Cette clause est généralement la dernière d'une instruction SELECT.

Combinaison avec d'autres fonctions

Dans la pratique, on peut distinguer deux méthodes de création des chaînes SQL. La méthode standard et la méthode utilisée quand les chaînes SQL contiennent des variables

Exemple de la 1ère méthode utilisée quand il n'y a pas de variables, mais seulement des rubriques des tables. L'objectif est la lisibilité et la standardisation de l'écriture.

Dim strSQL As String

strSQL= "SELECT DISTINCTROW Catégories.NomCatégorie, " & _
"Produits.NomProduit, " & _
"Catégories.Description, Categories.ImageCateg, " & _
"Produits.CodeProduit, Produits.QuantitéParUnité," & _
"Produits.PrixUnitaire, Produits.Abandonné " & _
"FROM Catégories " & _
"INNER JOIN Produits ON Catégories.CodeCatégorie = Produits.CodeCatégorie " & _
"WHERE ((Catégories="'Livres')) " & _
"ORDER BY Catégories.NomCatégorie, Produits.NomProduit;"

• Les mots clés sont en majuscule (FROM, WHERE, ORDER BY etc,).
• La chaîne SQL est assignée à une variable de type String (strSQL).
• Les lignes se terminent avec espace " espace & espace tiret de soulignement.
• Une nouvelle ligne débute par le signe " et sans espace derrière ce signe.
• Les lignes ont une longueur facilitant la lisibilité.
• Si une ligne est trop courte avec un seul mot clé, on peut en placer plusieurs. Ainsi, dans cet exemple, on a placé le mot clé ON sur la même ligne que INNER JOIN.

Exemple de la seconde méthode utilisée notamment quand un critère de recherche peut varier et doit être stocké dans une variable (ClauseWhere)..

Dim strSQL As String
Dim ClauseWhere As String

Select Case Me!cmdSelectionPar.Caption

strSQL = "SELECT DISTINCTROW '' As extraspace, NomRestaurant, id "
strSQL = strSQL & "FROM tblRestaurant " & ClauseWhere
strSQL = strSQL & " ORDER BY NomRestaurant ;"

Set rec = Bdd.OpenRecordset(strSQL)

On peut aussi définir le code de terminaison de la chaîne SQL sous forme d'une constante:

Public Const TerminaisonSql = ";"

Dans ce cas la chaîne sera terminée comme suit:

strSQL = strSQL & TerminaisonSql

Remarque:
Ecrire les instructions SQL dans le code VBA présente l'avantage de pouvoir supprimer les messages système d'avertissement affichés avant les mutations (insertion, suppression, mise à jour). A cet effet on utilise la méthode SetWarnings de l'objet DoCmd.

Dim strSql As String
strSql = "UPDATE tblAppels SET tblAppels.DernierAppel = Now(), ............."
' Désactiver les messages système d'avertissement
DoCmd.SetWarnings False
DoCmd.RunSQL strSql
' Rétablir les messages système d'avertissement
DoCmd.SetWarnings True

Une solution encore plus avantageuse est d'utiliser la méthode Execute de l'objet CurrentDb, car elle permet d'éviter de devoir désactiver / réactiver les avertissements.

Ainsi pour les ajouts on aura: CurrentDb.Execute "SELECT INTO..."
Pour les mises à jour on aura: CurrentDb.Execute "UPDATE..."
Pour les suppressions on aura: CurrentDb.Execute "DELETE..."

• Mettre les jointures en premier :
• Si n tables, alors (n-1) jointures.
• Placer les comparaisons les plus restrictives le plus tôt possible :
• cela fera toujours autant de lignes qui ne seront plus en mémoire, et que l'ordinateur n'aura plus à traiter dans le reste de sa requête
• EVITER ABSOLUMENT "SELECT * FROM ..." :
• Ne demandez que les colonnes nécessaires, c'est toujours ça de moins à garder en tableau temporaire après la requête, et donc cela économise la mémoire. De plus, si un jour vous déplacez votre code, et que deux colonnes se trouvent inversées dans la nouvelle base, cela n'aura aucune conséquence pour votre développement.
• Comparer des colonnes de même type :
• Un CHAR(110) est considéré du même type qu'un VARCHAR(110), mais différent d'un CHAR(112) ou d'un VARCHAR(108). Cela oblige le moteur de bdd à effectuer des conversions internes.
• Formuler les clauses de comparaison le plus précisement possible :
• En particulier, éviter de mettre des * partout dans les clauses LIKE, c'est très lourd à traiter...
• Mettre les identifiants en INT, et en NUMEROAUTO :
• L'avantage principal du numéroauto est que pour chaque création d'enregistrement ne comprenant pas d'office son identifiant, le moteur se charge de lui en attribuer un [du type max(id)+1], ce qui évite des manipulations supplémentaires.
• Utilisez des INDEX :
• Pour accélérer les recherches.

L'objectif est de regrouper les données, chaque groupe étant l'ensemble des lignes ayant une valeur commune. Nous devons donc indiquer à SQL comment il doit constituer les groupes et ce que l'on veut faire comme opération. C'est la clause GROUP BY qui nous permet de donner le regroupement à réaliser :

Nous pouvons ensuite étudier les caractéristiques de ces groupes: notamment en calculer l'effectif. Par exemple, à partir d'une base de suivi de visites d'un site on peut regrouper les données par serveur d'origine, par moteur de recherche, par date de visite.

Exemples
Prenons une table d'individus dont nous connaissons les dates de naissance, il peut être intéressant de connaître le nombre de personnes par année de naissance.

SELECT year(dateDeNaissance) AS Année, count(*) As Nombre FROM tblHabitants GROUP BY Année

Voilà un extrait du résultat :

Le résultat nous est donné trié par année, nous pouvons l'obtenir trié sur le nombre :

SELECT year(dateDeNaissance) As Année, count(*) AS Nombre FROM tblHabitants GROUP BY Année ORDER BY count(*)

Sélectionner les groupes
SQL autorise de ne manipuler que les groupes vérifiant certaines conditions; nous pourrions ne nous intéresser qu'aux individus dont le code postal est 1000. Il faut alors utiliser HAVING qui est à GROUP BY ce que WHERE est à SELECT.

SELECT year(dateDeNaissance) AS Année, count(idElement) AS Nombre, CodePostal FROM tblHabitants GROUP BY Année HAVING CodePostal = '1000'

Par exemple, nous pourrions très bien n'étudier que les groupes d'année de naissance pour les femmes :

SELECT year( dateDeNaissance) AS adn, count(idElement) AS cpt FROM tblHabitants WHERE sexe = 'F' GROUP BY dateDeNaissance

On se rend alors compte que la clause HAVING ci-dessus peut-être remplacé par une clause WHERE, et de façon plus pertinente puisque nous éliminons des lignes avant de les regrouper. L'exécution sera donc plus rapide.

La clause HAVING est intéressante quand elle porte directement sur une valeur issue du regroupement. Intéressons-nous par exemple aux groupes dont les effectifs sont supérieurs à 10 :

SELECT year( dateDeNaissance) AS adn, count(idElement) AS cpt FROM tblHabitants GROUP BY adn HAVING cpt >10 ORDER BY cpt

Solution:
Une possibilité est de fonder l'état sur une requête de totalisation utilisant la fonction domaine DSum. Dans notre exemple, la requête est basée sur une table dénommée tblVentes contenant les rubriques NoMois et MontantMensuel .auxquelles on adjoindra un champ calculé indépendant dénommé CumulVentes.

Ainsi, on aura le code SQL suivant qui balaye la table enregistrement par enregistrement: et calcule le cumul tant que le contenu de la rubrique NoMois est inférieur ou égal à celui de l'enregistrement courant.

SELECT tblVentes.NoMois, tblVentes.MontantMensuel,
DSum("MontantMensuel","tblVentes","NoMois <=" & [NoMois]) AS CumulVentes
FROM tblVentes
ORDER BY tblVentes.NoMois;

Il arrive souvent qu'un total ou un soustotal doive être calculé à partir d'une source différente du recordset sous-jacent d'un formulaire. Par exemple, dans un formulaire affichant les données clients, si on veut présenter le total du chiffre d'affaires réalisé avec chacun. En effet, on devra notamment balayer les enregistrements de la table Détails commandes, à l'aide d'une requête de totalisation. Malheureusement cette approche rend le formulaire dépendant d'un objet supplémentaire. Si on veut l'utiliser dans une autre application, il faudra aussi y importer la requête appropriée.

Pour éviter ceci et augmenter la performance, il est avantageux de recourir au concept d'encapsulation de la technologie orientée objets. Il s'agit tout simplement d'encapsuler la logique de la requête de totalisation dans le formulaire. A cet effet, le module intégré au formulaire clients, contiendra la fonction calculant le total, par exemple:

Private Function CalculTotalVenteClient()
Dim rs As Recordset, strSQL As String
strSQL = "SELECT tblClients.CodeClient, " & _

Pour afficher le résultat, on crée une zone de texte indépendante, dont la propriété Source contrôle sera réglée comme suit: =CalculTotalVenteClient()

Ainsi, plus besoin de documenter ou de se rappeler les concordances entre requêtes et formulaires.