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
Webmaster
�Imprimer
�Donner votre avis