ETRE BON, C'EST SAVOIR SE PROTEGER
Les grands manitous du Web nous l'ont tous dit : lors de la ruée vers
l'or, ce sont les marchands de pelles qui se sont enrichis. A les entendre,
il semble possible d'affirmer que les grands gagnants de la course folle
de l'Internet soient les informaticiens. Leurs doléances sont maintenant
exprimées : difficultés à nous recruter, salaires scandaleux, obligation
de nous augmenter tous les six mois, il semblerait que nous ne nous soyons
jamais aussi bien porté que depuis ces dernières années. Et visiblement,
ils n'ont pas aimé. Or, actuellement, certaines entreprises ferment. Il
devient plus facile de recruter de la "main d'oeuvre". Et cela, par contre,
à l'air de beaucoup leur plaire. Pourtant, personne ne parle jamais des
journées de 14 heures dans les parcs à informaticiens (box), voir même
des heures de nuit ou de Week End devant son écran "pour la bonne cause".
La conséquence est claire : maintenant plus encore qu'hier, tout informaticien
devra donc rapidement apprendre à se protéger, sous peine de se laisser
manger par son travail et sa direction commerciale et marketing. Il devra
mettre des barrières et imposer ses délais aux décideurs (patrons, clients,
...) qui oublient un peu vite que nous sommes pas que des outils, mais
qu'en revanche nous sommes totalement indispensables à la conception des
jolis projets qu'ils nous demandent. Et que la fiabilité desdits projets,
et donc la pérennité des entreprises qui les utilisent, dépend en grande
partie de la qualité de notre production. Il existe un moyen infaillible
de se protéger, et donc de rester performant dans son travail : être bon,
être réellement professionnel. Afin que notre code nécessite le moins
de retouches possibles, et qu'il convienne parfaitement à la demande des
utilisateurs. Ainsi, nous serons tous gagnants : les programmes seront
performants, et les informaticiens auront moins de pression. Il faut que
les utilisateurs prennent confiance en notre travail...
RAPPEL : SELECT ... FROM ... WHERE ... GROUP BY ...
Reprenons le modèle de la coupe du monde Football de 1998 tel que nous
l'avons vue dans la partie
5 :
MCD
|
MPD
|
SELECT NOMPAYS, count(IDBUT)
FROM JOUEUR, BUT, COMPOSERDE, EQUIPE, PAYS
WHERE JOUEUR.IDJOUEUR=BUT.IDJOUEUR
AND JOUEUR.IDJOUEUR=COMPOSERDE.IDJOUEUR
AND COMPOSERDE.IDEQUIPE=EQUIPE.IDEQUIPE
AND PAYS.IDPAYS=EQUIPE.IDPAYS
GROUP BY NOMPAYS
renverra, pour chaque pays participant, le nombre total de buts marqué
durant la compétition.
La requête concerne 5 tables, elle nécessite donc 4 jointures. Le détail
des clauses
WHERE,
GROUP BY et des
Agrégats a été
vu dans la
partie
6
LANGAGE SQL : LA CLAUSE HAVING
La clause HAVING définit les critères de la clause GROUP BY
de la même façon que la clause WHERE dans une instruction SELECT.
L'avantage de la clause HAVING est surtout qu'elle peut comporter
des agrégats, ce que ne permets pas la clause WHERE.
SELECT NOMJOUEUR
FROM JOUEUR, BUT
WHERE JOUEUR.IDJOUEUR=BUT.IDJOUEUR
HAVING count(BUT.IDJOUEUR) > '2'
retournera la liste des joueurs ayant marqué plus de deux buts.
Il est possible de combiner les critères avec les opérateurs AND
et OR.
LANGAGE SQL : LA CLAUSE ORDER BY
La clause ORDER BY permet de trier les résultats d'une requête
par colonnes. Il est possible de demander un tri croissant (asc)
, ou décroissant (desc). Par défaut, le tri est croissant (asc).
Plusieurs colonnes peuvent être indiquées : dans ce cas, le tri sera effectué
selon la première colonne indiquée, puis la deuxième, etc...
SELECT TAILLE, POIDS, NOMJOUEUR
FROM JOUEUR
ORDER BY TAILLE desc, POIDS desc
retournera la taille, le poids et le nom des joueurs participants au tournoi,
mais du plus grand au plus petit : en cas de taille équivalente, les plus
lourds seront retournés en premier.
Cette clause est très importante : en effet, elle permet à elle seule
d'effectuer un classement des données, et donc d'éviter de programmer
un traitement supplémentaire généralement très lourd en ressource système
et en mémoire.
Il est possible d'utiliser le numéro des colonnes plutôt que leur nom.
SELECT POSITION, avg(TAILLE)
FROM JOUEUR
GROUP BY POSITION
ORDER BY 2
retournera la taille moyenne des joueurs positions par positions, de la
taille moyenne la plus petite à la plus grande. Cela peut se révéler très
utile, notamment pour des tableaux de statistiques. Et surtout, les données
arrivent déjà trillées.
LE LANGAGE SQL EST LA BASE DU DEVELOPPEMENT
Ces deux articles n'ont pas la prétention de remplacer un ouvrage technique,
ou la documentation officielle. Seulement, les requêtes SQL sont la trame
du développement d'un site dynamique. Une base bien conçue permettra de
gérer avec cohérence les données, et ainsi d'éviter un certain nombre
d'erreurs. La requête SQL permet d'extraire ces données, le langage de
développement s'occupant de la présentation de ces données et de la gestion
des tests souvent nécessaires, voir même de la mise en page. De plus,
il ne faut pas perdre de vue que les appels à la base de donnée sont de
grands consommateurs de ressources systèmes : il importera donc de bien
doser leur utilisation, et surtout d'utiliser toutes les possibilités
du SQL afin d'obtenir le maximum d'informations dans la même requête.
J'en ai encore eu la confirmation lors des deux derniers évènements auxquels
j'ai assisté, un déjeuner/débat avec des acteurs de l'Internet Français
et Européens (entrepreneur et investisseurs), et le First Tuesday du mois
d'Avril (avec le fondateur de Self Trade) : l'heure est à la crise financière
pour les projets Internet non-viables, mais l'avenir est surtout au sites
dynamiques. Les entreprises ne se satisfont plus de sites 'plaquettes',
elles veulent maintenant une plus grande dimension informatique et technique
pour leur Internet.
A bientôt...
Tous droits réservés - Reproduction même
partielle interdite sans autorisation préalable