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.