été 2013: Actuellement Responsable de la Société Smongdee IT ASIA Co., Ltd.: www.IT-Asia.com
Go to the English version

Irish PHP User's Group

Merise: 7ème Partie Dossier "SAM l'Informaticien" du 04 au 15 Avril 2001
par
Stéphane Lambert

ous voici à la troisième étape du développement de votre projet Web : l'architecture a été définie (choix matériels et technologiques), la base de donnée (cohérente...), a été analysée et construites dans les règles de l'art... Il s'agit maintenant d'utiliser au mieux tout ceci afin de construire les pages dynamiques qui afficheront aux visiteurs les informations qu'ils ont demandés, ainsi que celles que votre employeur/client désire mettre en avant. C'est à ce stade que le langage SQL intervient. Or, ses possibilités sont sous-estimées, et donc ses fonctionalités souvent sous-employées. Pourtant, c'est le fer de lance de la partie dynamique du site Web. Une des parties les plus coûteuses en ressources systèmes, aussi... Car insérer et extraire des données sollicite fortement le(s) disque(s) dur(s) (HDD), utilise de la mémoire (RAM) et du temps système (CPU). Il importera donc non seulement d'utiliser les bonnes requêtes aux bons moments, mais aussi de les rédiger le plus proprement possible afin d'éviter au maximum le gaspillage des ressources du ou des serveurs abritant la base de donnée.

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...

<< Lire la 6ème partie

Stéphane Lambert
http://www.vediovis.fr/

Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.

 

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable