Top 5 des erreurs à absolument éviter en SQL
Actuellement, SQL est la vie. La plupart des bases de données comprennent le langage SQL. Vous pouvez interroger des bases de données NoSQL avec Presto. Presto utilise la syntaxe du langage SQL. La syntaxe du langage CQL utilisé par Cassandra est aussi proche de celle de SQL. Ainsi, vous n’avez pas besoin d’apprendre un langage spécifique pour chaque type de bases de données. SQL est essentiel!
En Data Science, SQL permet d’extraire facilement à partir des bases de données, des informations très importantes facilitant la prise de decision de qualités en Entreprise.
Cependant, il est important d’éviter certaines erreurs afin d’augmenter la performances de vos requêtes SQL.
Dans cet article, je vous présente 5 erreurs à absolument éviter en SQL.
1. Utiliser le distinct
En SQL, pour récupérer des valeurs distinctes :
Au lieu de faire ceci :
SELECT distinct colonneName
FROM tableName;
Faites plutôt ceci :
SELECT colonneName
FROM tableName
GROUP BY colonneName;
Vous pouvez aussi utiliser un CTE ou une sous requête.
La deuxième requête engendre moins de coût que la première et est donc plus performante.
2. Utiliser la position d'une colonne dans une requête SQL
Au lieu de faire ceci :
SELECT order_id, order_date
FROM orders
ORDER BY 2;
Faites plutôt ceci :
SELECT order_id, order_date
FROM orders
ORDER BY order_date;
Il faut toujours utiliser le nom de la colonne.
Cela rend votre code plus lisible et compréhensible.
3. Ne pas utiliser la Majuscule pour les mots Clés de SQL
Au lieu d’écrire ceci en SQL :
select nom, prenom from personnes;
Écrivez plutôt ceci :
SELECT nom, prenom FROM personnes;
Il faut toujours utiliser la Majuscule pour les mots clés de SQL et la Minuscule pour les noms de tables et colonnes. Cela augmente la lisibilité de votre code.
4. Utiliser le SELECT *
Au lieu de faire ceci en SQL :
SELECT * FROM NomDeLaTable;
Faire plutôt ceci :
SELECT colonne1, colonne2, .etc. FROM NomDeLaTable;
La première requête détruit la performance.
Il faut surtout l’éviter si la requête sera exécutée en production.
5. Exécuter directement des requêtes SQL analytiques ou complexes en Production
Les requêtes analytiques sont souvent des requêtes complexes nécessitant une puissance de calcul importante.
Si vous exécutez en production pendant les heures de pointes où le système opérationnel est très sollicité, cela peut impacter la performance et ralentir certaines opérations qui sont plus importantes pour le business.
C’est donc plus performant de planifier l’exécution des requêtes analytiques hors des périodes de pointes.
En se basant sur les informations de connexion des utilisateurs, vous pouvez déterminer les périodes où les utilisateurs sont plus connectés et ne pas exécuter aucune requête analytique complexe pendant cette période.
Généralement, entre 3 et 5 AM les systèmes sont moins sollicités. C’est le meilleur moment.
6 . Ne pas indenter et aligner sa requête SQL
Au lieu de faire ceci en SQL :
SELECT order_id, order_date, sales_id, customer_id FROM NomDeLaTable WHERE
customer_id< 50
Faites plutôt ceci :
SELECT order_id,
order_date,
sales_id,
customer_id
FROM NomDeLaTable
WHERE
customer_id< 50
La seconde requête est plus facile à lire que la première.
7. Ne pas utiliser le même type de cas cohérent pour les schémas, les tables et les colonnes de sa requête
Au lieu de faire ceci en SQL :
SELECT orderId,
orderdate,
sales_id,
customer_id
FROM orders
Faites plutôt ceci :
SELECT order_id,
order_date,
sales_id,
customer_id
FROM orders
Il existe plusieurs types de case en programmation. Nous avons par exemple :
- snake_case
- PascalCase
- camelCase
Il est conseillé d’utiliser le même type de case dans son code. Cela rend le code plus cohérent et lisible.
