Développement en SGBDR Epais - Introduction / Outils / Astuces

Jc · 02-05-2012 02:59:24

Bonjour,

Pour ceux qui me suivent un peu sur le forum, je pense que vous aurez déjà compris que je privilégie / que je suis partisan des développements en SGBDR épais dans tout développement web, ou dit différemment, des développements dont le coeur de l'application est géré au niveau du serveur de base de données.
Dans un environnement web, on trouve à la base au moins 3 éléments distincts séparés physiquement les uns des autres (il peut y en avoir plus).
- Le Serveur Base de données (SGBDR)
- Un Serveur Tiers (En général un serveur PHP) associé au serveur apache (http) qui peuvent être séparés physiquement. Le protocole HTTP est la couche applicative sur laquelle votre application va communiquer sur tout le réseau et qui relie l'ensemble des serveurs au client.
- Le client (Navigateur Web)
Dans un tel contexte il parait donc tout simplement évident que le facteur pénalisant dans toute application sont les temps de communications entre ces trois éléments. Optimiser une application, consiste d'abord donc a architecturer l'application de façon à ce qu'une communication entre un de ces trois éléments et un autre s'effectue que lorsque celle-ci est absolument nécessaire et le moins de fois possible. Pour cela il est important de comprendre leur nature.

- Le SGBDR est un serveur relationnel. Il est capable d'éxécuter des actions en parallèle les unes des autres. Il est naturellement optimisé et conçu pour prendre en charge automatiquement sans rajouter une seule ligne de code, un processeur en plus et de la mémoire principalement. Il est naturellement optimisé pour effectuer des jointures entre les tables de données et il est imbattable pour trouver une information parmis des millions de lignes de données. Il est par contre limité dans sa capacité a effectuer des calculs mathématiques conséquents.

- Le serveur PHP ou serveur Objet. Il est optimisé pour utiliser des objets, faire des calculs. Les notions de parallélisme et de prise en charge nativement des ressources processeurs, mémoire ou disque sont initialement absentes. Il faut donc les développer / utiliser des bibliothèques spécifiques pour accéder à ce niveau de fonctionnalités.

- Le client, ou pourrait-on dire l'IHM : L'interface Homme Machine. C'est le client (le navigateur web) qui va gérer l'affichage et le rendu des données, qui va les rendre accessible à l'utilisateur.

Bien que le développement en base de données épaisses implique que le serveur tiers et le client soient les plus fins possibles au niveau code, personnellement je diverge un peu de ce concept concernant le client. Pourquoi et comment? Tout simplement car les applications se veulent être dotées aujourd'hui d'une interface riche, agréable et puissante. Et ceci implique de fait un développement conséquent du côté client avec des technologies clientes (ex: javascript, jQuery) ou mixtes avec le serveur tiers (ex:silverlight) . Mais attention il ne faut pas tout confondre. Cela reste à mon sens compatible avec la notion de SGBDR épais, car le coeur de l'applicatif reste géré à ce niveau. En effet, comme il a été présenté un peu plus haut, il ne faut pas oublier qu'une application n'est rien d'autre que faire intéragir des données avec l'utilisateur, et que les données sont le centre de tout. Il convient donc d'en prendre soin et de veiller d'abord à préserver leur intégrité, leur atomicité et leur consistence.

Bien qu'il soit évident également qu'un site ecommerce simple n'a pas les mêmes besoins et mêmes exigences structurelles d'une véritable application web (intranet d'entreprise, application en paas, saas, extranet, etc...) il n'en reste pas moins évident à ce stade que plusieurs problèmes se posent déjà

- Plus des 3 quarts des CMS du marché ne respectent pas ni ne sont optimisés pour respecter les spécificités métier de chaque serveur ainsi que tout ce qui a été présenté jusqu'ici. Ils n'utilisent par exemple les bases de données QUE pour gérer la persistence des données.
- Beaucoup de Patterns de développement connus et utilisés en PHP (aussi par ces mêmes CMS) quand ils ne sont pas préconisés voire rendus indispensables, vont à l'encontre de tout ce qui a été dit jusqu'ici. Attention, ces patterns ont cependant leur raisons d'être et continuent d'avoir leur raison d'être, mais malheureusement dans un autre contexte de developpement que celui d'un contexte client-serveur sur internet. J'aurai l'occasion de développer en détail cette partie prochainement.

Je vais terminer cette introduction en apportant deux à trois réponses aux développeurs PHP qui souhaiteraient passer en développement SGBDR épais mais qui se demandent de façon immédiate comment faire certaines choses en SQL qui leur paraissent impossible ou trop long/coûteux à faire.

- Pour illustrer la première, prenons le cas d'une procédure transactionnée pour créer un client, dont le nombre de paramètres est important, du moins suffisamment pour rendre fastidieuse la tâche en apparence, disons 30 paramètres.
En php, c'est simple, on mets tout ça dans un array ou plusieurs et avec PDO via une ou plusieurs requête(s) préparée(s), en deux lignes de code la ou les requêtes de création sont faites.
Or on ne peut pas créer de variables tabulaires en SQL, cela n'existe pas, du moins si, mais cela s'appele une table. Le développeur PHP abandonne de suite là car il se refuse à passer les 30 paramètres un à un à une procedure stockée MySQL/SQL et à les gérer également 1 par 1 dans la procédure. Du coup il continue à faire cela en PHP à tort.
La solution? On prends notre array en PHP, on fait un explode et on passe notre belle chaîne de caractères en un seul paramètre à notre procédure stockée, en prenant bien soin de bien choisir notre séparateur de champ. Certains diront de suite: "Gros malin tu fais comment pour parser ta chaîne de caractères en SQL?" Tout simplement avec une petite astuce mathématique qui ne prends pas de ressources sur le serveur SQL comme suit :

DELIMITER $$

-- Pour compter combien de paramètres contient notre chaîne de paramètres

CREATE FUNCTION getOccurence (basestring VARCHAR(255), pattern VARCHAR(30)) RETURNS SMALLINT DETERMINISTIC

RETURN FLOOR(( LENGTH(basestring) - LENGTH(REPLACE(basestring, pattern, '')) ) / (LENGTH(pattern)));$$

-- Pour retourner le paramètre n numérique de la chaine. Retourne 0 si le paramètre est une chaîne.

CREATE FUNCTION get_offstring(inputstr VARCHAR(100),relpos TINYINT UNSIGNED) RETURNS INT UNSIGNED

BEGIN

    DECLARE slice VARCHAR(100) DEFAULT "";

    SET @nbo = getOccurence(inputstr);

    IF relpos<=0 OR relpos > @nbo+1 THEN RETURN CAST(0 AS UNSIGNED); END IF;

    IF @nbo=0 THEN RETURN CAST(inputstr AS UNSIGNED); END IF;

    SET @idx=1; SET @c=1;

    WHILE @idx<>0 DO

        SET @idx=INSTR(inputstr,',');

        IF @idx<>0 THEN  

            SET slice=LEFT(inputstr,@idx-1);

        ELSE

            SET slice=inputstr;

        END IF;

        IF @c=relpos THEN RETURN CAST(slice AS UNSIGNED); END IF;

        SET inputstr=RIGHT(inputstr,LENGTH(inputstr)-@idx);

        SET @c=@c+1;

    END WHILE;

END;

Ce n'est pas plus compliqué que cela. Si vous souhaitez récupérer n'importe quel paramètre sous forme de chaîne, c'est encore plus simple!
Plus d'excuses pour ne plus faire vos créations en procédures stockées SQL.

A bientôt pour la suite!

Dernière modification par Jc (15-07-2013 17:15:17)

Jc · 02-05-2012 12:26:58

Bonjour,

Merci pour ton retour MK. Tu as parfaitement raison, Mon raccourci était un peu trop raccourci^^; je viens d'ailleurs de rectifier sur mon post pour l'essentiel.

[MK]Ok, du coup je vire mon post qui pollue désormais inutilement ce sujet.[/MK]

Maljuna Kris · 02-05-2012 13:13:39

Bon, avec un peu plus de recul, une remarque sur la forme.
Tu sembles avoir perdu de vue que nous sommes sur PHP DEBUTANTS.
Je pense que nos amis n'auraient rien contre une illustration concrète de l'utilisation de l'exemple que tu fournis.

Par ailleurs, une question, pourquoi n'y-a-t-il pas de DELIMITER pour la déclaration de la deuxième procédure ?

[PS]Je sais, c'est tordu, mais avoir tort se termine par un t (j'ai corrigé ton exposé)[/PS]

Jc · 02-05-2012 23:45:03

Suite à la demande justifiée de MK, voici quelques explications sur le code fourni.

- Concernant le DELIMITER, il sert à délimiter les deux fonctions contrairement au ; qui sert à délimiter les instructions. Le DELIMITER par défaut est le ; ce qui oblige à le changer pour pouvoir définir deux procédures/fonctions différentes dans la même "action" ou portée de code. Ainsi il est inutile d'en définir un à la fin au même titre que l'on en aurait pas mis si une seule fonction avait été définie.

- Maintenant voici un exemple d'application. Pour l'exemple je vais limiter une création de CLIENT à une table de 2 champs + clé primaire. On peut à partir de là aisément l'étendre à plus de colonnes, évitez d'ailleurs un trop grand nombre de colonnes et privilégiez des structures à moins de 20 colonnes à chaque fois que cela vous est possible. Pourquoi j'ai pris dans mon exemple initial une chaîne de 30 paramètres? Cela ne signifie aucunement que ma table client possède 30 colonnes mais que la procédure de création d'un CLIENT (utilisant plusieurs tables) nécéssite une trentaine de paramètres.

Imaginons que ces 30 paramètres sont utilisés dans une procédure de 3 requêtes utilisant chacune 10 paramètres. C'est un peu contraignant par rapport à PHP certes, mais il va falloir passer ces paramètres dans des variables locales, soit via un DECLARE soit via une variable utilisateur, locale elle aussi, avec le préfixe @. Pourquoi? simplement pour optimiser la longueur de code et les ressources utilisées si l'on a besoin d'effectuer un ou des traitements sur le paramètre (vérification,etc...) avant de le passer dans la requête. Tout comme dans une table normalisée le type de chaque variable doit être optimisée en fonction du paramètre.
Admettons donc que le caractère de séparation de champs soit la virgule on récupérera chaque paramètre de la façon suivante

-- on vérifie d'abord que le nombre de paramètres passés à la procédure est bien celui attendu

DECLARE nbo INT DEFAULT 0; -- nbo= nb d'occurences de séparateur de champs trouvés

SET nbo=getOccurence("machaine_paramètres",",");

DECLARE var1 INT DEFAULT 0;

DECLARE var2 INT DEFAULT 0;

...

SET var1=get_offstring("machaine_paramètres",1); -- on récupère le premier paramètre de la chaine (numérique)

SET var2=get_offstring("machaine_paramètres",2); -- on récupère le second paramètre de la chaine (numérique)

...

INSERT INTO CLIENTS (param1,param2) VALUES (var1,var2);

...

Voilà donc l'utilisation du code.

PS: Vous noterez que j'ai parlé de traitement de vérifications de chaque paramètre avant de les passer dans leur requêtes respectives. Ceci est fondamental et ne doit pas être négligé car il en va de la qualité de vos données et de leur intégrité. Vous ne pouvez pas vous permettre de vous en remettre au code applicatif pour valider les paramètres passés à votre procédure, au même titre que vous ne devez pas le faire entre deux fonctions PHP.

++

Dernière modification par Jc (15-07-2013 17:16:10)

Maljuna Kris · 03-05-2012 06:40:01

Merci et, encore un petit effort, Jc.
Si l'on comprend bien que le séparateur de paramètres, dans l'exemple, est la virgule :

--rappel de la déclaration de la fonction

CREATE FUNCTION getOccurence (basestring VARCHAR(255), pattern VARCHAR(30)) RETURNS SMALLINT DETERMINISTIC

SET nbo=getOccurence("machaine_paramètres",",");

où "," correspond à l'argument pattern de la déclaration de la fonction; le débutant peut être dérouté par ce type d'utilisation du SQL dit "procédural".
Donc, (je sais, je suis exigeant, mais le sujet le requiert, non ?), il manque, dans ton exposé comme dans ton illustration, la mise en œuvre de ce code au sein de l'application.
Pour être plus précis, comment passe-t-on de la réception du formulaire soumis au navigateur à l'appel de cette procédure ?
Je ne doute pas que tu nous éclaire rapidement à ce sujet aussi.

Et encore bravo, pour les efforts et l'initiative de cette démarche.

Jc · 04-05-2012 04:36:17

Bonjour,

Les contextes d'appel de création de ligne (vulgairement enregistrement) en php sont au nombre de deux.

1) Via un formulaire de saisie HTML envoyé à une page PHP de traitement en GET ou POST
Rien de plus classique

// on récupère les variables en s'assurant qu'elles existent

$param1="";$param2=""; // on ne prends que deux variables chaîne de caractère comme exemple.

if (isset($_POST["param1"])){$param1=$_POST["param1"];}

if (isset($_POST["param2"])){$param2=$_POST["param2"];}

// On construit la chaîne de paramètres au SGBDR

$chaine=addslashes($param1).','.addslashes($param2);

// Via un Objet PDO connecté à votre base de données on éxécute une simple requête

$myPDO->query("CALL nom_de_ma_procedure_stockee('$chaine')");

Deux choses importantes à dire à ce niveau
- Pas besoin de créer un contexte transactionné au niveau de PDO, cela doit être fait au niveau de votre procédure dans le SGBDR.
- Si votre procédure stockée gère les erreurs avec l'instruction SIGNAL de la version 5.5 de MySQL, et que votre procédure retourne une erreur, l'erreur doit être récupérée via le gestionnaire d'erreur de PDO.

2) Via une requête Ajax
La chaine de paramètre peut être construite directement au niveau du javascript et transmise à PHP via JSON ou normalement ou chaque paramètre peut être transmis à php indépendament les uns des autres (même cas de gestion que précédemment).
Si les paramètres sont transmis en JSON par exemple un simple

$tmp=json_decode($_POST['params']);

$chaine=addslashes($tmp->param1).','.addslashes($tmp->param2);

//puis comme précédemment

$myPDO->query("CALL nom_de_ma_procedure_stockee('$chaine')");

suffit.

Et voila, la délégation de la gestion des données passe du côté SGBDR. Vous pouvez donc vous consacrer coté PHP et client à la gestion de votre interface et des interactions utilisateurs pleinement.

Dernière modification par Jc (15-07-2013 17:16:45)

Maljuna Kris · 04-05-2012 07:30:16

Elle est pas belle, la vie ?

Bon les débutants vont tousser, comme d'hab.

Je les entends déjà :

Euh... c'est quoi PDO et sa gestion des erreurs ?

ou bien encore

vous avez dit AJAX, et pis JSON ? KEZAKO ?

Ah les ingrats ! Faut vraiment tout leur dire !

Il y a bien un moment, tout de même, où on va leur sortir le traditionnel "LTDM"

LTDM => Legu Tiun Diablan Manlibron.
(en français : RTFM Read That Fucking Manual)
nom de Diouss !

Encore merci à Jc.

Ça a de la gueule cet exposé, non ?

moogli · 07-05-2012 00:14:42

Yop,

pourquoi addslashes ?

Alors que PDO propose la méthode quote

Le coté rappel d'utilisation de mysql (fonction, proc stock, validation sur le SGBDR) est sympa, c'est vrai que l'on vois rarement ce genre de chose dans les tutos.
Par contre je trouve que ce type de fonctionnement, perd la lisibilité du code et impose un traitement en plus.

le coté perf, je connais pas, et je reste étonné

Ils n'utilisent par exemple les bases de données QUE pour gérer la persistance des données.

heu c'est le role d'un sgbd dans une appli n-tiers, ou je n'ai pas compris le sens de la phrase :s
La validation des données étant, bien sur a réaliser aussi sur le SGBDR (et la gestion d'intégrité si besoin) peut être est ce que tu entend par la.

@+

Jc · 07-05-2012 14:11:04

Bonjour,

Et merci moogli pour ton retour. Avant de te répondre, je dirai que je m'y attendais et je pense que tu es le premier d'une longue liste en termes de retour de ce type.

Tout d'abord la méthode quote de PDO comme chacun doit le savoir, n'est pas nouvelle, elle est issue de son équivalent SQL que mySQL implémente.
Pour ceux qui ne la connaissent pas voici par exemple une différence d'écriture entre un quote et un addslashes

// avec QUOTE

$myPDO->query("INSERT INTO CLIENTS (param1,param2) VALUES (QUOTE($param1),QUOTE($param2))");

// avec addslashes

$myPDO->query("INSERT INTO CLIENTS (param1,param2) VALUES ('".addslashes($param1)."','".addslashes($param2)."');

J'aurais pu donc en effet utiliser QUOTE mais pas en tant que méthode mais plutôt en tant qu'instruction comme suit

$chaine="$param1,$param2";

$myPDO->query("CALL nom_de_la_procedure_stockee(QUOTE($chaine))");

J'ai juste voulu utiliser une écriture que des débutants ont l'habitude d'utiliser pour rester plus compréhensible.

Pour le reste que tu soies étonné, moi je ne le suis pas. Il s'agit là de l'introduction de mon exposé, et la première partie sera justement consacrée à la place de PHP dans le "couple" PHP-MySQL" ou plus généralement "PHP-SGBDR".

wikipedia architecture n-tiers a écrit :

...
rupture du lien de propriété exclusive entre application et données. Dans ce modèle, la base de données peut être plus facilement normalisée et intégrée à un Entrepôt de données.
...

Même si ici Entrepôt de données = datawharehouse ce qui change l'architecture applicative et le contexte, le gros problème de cette phrase ce sont les immenses incompatibilités suivantes
- Si entrepôt de données est vu comme un lieu de stockage de données (ce qui déjà est un non sens dans le contexte de la phrase car il est question je le rappele d'un datawharehouse), comment parler de normalisation lorsque par définition une base de données dédiée à la gestion de persistance, ne peut l'être, puisque la logique métier n'y est pas implémentée.
- Un datawharehouse n'a jamais représenté une base de données normalisée et il ne peut en être ainsi.

Je t'invite donc à attendre la première partie de mon exposé pour éclairer ta lanterne. Une fois fait, n'hésite pas à me faire un retour

++

moogli a écrit :

Par contre je trouve que ce type de fonctionnement, perd la lisibilité du code et impose un traitement en plus.

Ne t'inquiète pas, je n'oublierais pas et en aucun cas de répondre à cette remarque dans cette première partie, car c'est plutôt une objection très répandue vis-à-vis des développements en SGBDR épais.

Dernière modification par Jc (15-07-2013 17:17:41)

Maljuna Kris · 07-05-2012 15:56:33

Tiens, Ranuleto, toujours vivant ?

Puisque Jc n'est pas présent, pour le moment, je vais répondre, en partie, à tes objections.

Pour PDO::quote, tant qu'à faire, je préconiserais PDO::prepare et PDOStatement::execute

Si vous utilisez cette fonction pour construire des requêtes SQL, vous êtes vivement invités à utiliser PDO::prepare() pour préparer les requêtes SQL avec des paramètres liés au lieu d'utiliser PDO::quote() pour interpréter les entrées utilisateur dans la requête SQL. Les requêtes préparées avec des paramètres liés sont non seulement plus portables, plus souples et plus sécuritaires, mais bien plus rapides à exécuter que d'interpréter les requêtes, étant donné que les côtés client et serveur peuvent mettre en cache une version compilée de la requête.

Je laisse à Jc le soin de justifier éventuellement le recours à addslashes.

Moogli a écrit :

heu c'est le rôle d'un sgbd dans une appli n-tiers, ou je n'ai pas compris le sens de la phrase :s
La validation des données étant, bien sûr à réaliser aussi sur le SGBDR (et la gestion d'intégrité si besoin) peut être est ce que tu entend par la.

C'est une partie de son rôle, mais une partie seulement. La notion de SGBD épais, embarque l'idée que tout ce qui peut utilement être fait par le SGBD doit lui être confié.
Ça va un peu à l'encontre d'un des dogmes de la conduite des projets des années 80 (séparer les données des traitements) mais ce n'est pas un retour en arrière, ce ne sont plus les données qui sont intégrées dans les traitements (cf la DATA DIVIVION du CØBØL), mais certains traitements qui sont confiés au SGBD.

Quant à la lisibilité du code, c'est là un vaste débat.
Je préfère, et de loin, le recours à des procédures stockées que l'utilisation d'un SGBD pour y stocker des pages HTML ou des scripts PHP ou d'autres langages.
Personnellement, j'ai, par exemple, quelques difficultés conceptuelles pour concilier un SGBD épais avec un pattern comme MVC (Modèle, Vue, Contrôleur), mais mes limites ne sauraient constituer un critère suffisant pour rejeter cette approche ô combien prometteuse.

Jc · 07-05-2012 19:33:59

Maljuna Kris a écrit :

Puisque Jc n'est pas présent, pour le moment, je vais répondre, en partie, à tes objections.

Je suppose que tu as oublié tes lunettes

Jc · 07-05-2012 20:10:16

Ah j'ai oublié une chose.

Concernant ta réponse MK à utiliser une requête préparée au lieu de QUOTE() ou $myPDO->quote() je suis en désacord avec toi sur le principe d'utiliser une requête préparée sous seul prétexte d'éviter les problèmes d'injection SQL. En effet l'intérêt primaire d'une requête préparée est de pouvoir effectuer une même requête effectuée de multiples fois avec des paramètres différents. Or si un seul traitement est nécessaire la requête préparée perd de son sens car elle est moins performante pour une seule requête que son équivalente non préparée.

Puisque toutefois l'objet de ce post est le développement en SGBDR épais, il y a une exception à ce que je viens de dire dans un contexte de procédure stockée sous MySQL et dû essentiellement aux limitations de MySQL, limitations qui n'existent pas au sein d'un vrai SGBDR comme SQL Server ou dans une moindre mesure postgreSQL.

Je m'explique.
Une requête préparée est une requête qualifiée communément comme requête dynamique car les paramètres passées à la requête sont définies par des variables. En d'autres termes on ne connait la valeur des variables passées à la requête qu'au moment de l'éxécution.
Ceci étant dit, une requête statique (dont tous les éléments sont connus et fixés à l'écriture du code) peut être construite dynamiquement ne serait-ce que pour éviter de créer une procédure stockée par requête de traitement. Il se trouve qu'une telle requête est appelée et considérée à tort comme une requête dynamique. Vous trouverez un exemple sur ce forum dans ce post. Or, pour éxécuter une telle requête dans une procédure stockée mySQL, et bien qu'elle soit statique, on est obligé de passer par une requête préparée dans mySQL.
Il faut savoir qu'utiliser une requête préparée dans mySQL entraine une limitation importante qui est l'impossibilité d'utiliser un curseur. Par conséquent si votre requête retourne plusieurs lignes vous serez obligé de passer par une concaténation de lignes par colonne avec GROUP_CONCAT pour pouvoir les traiter (utiliser les 2 fonctions données dans l'introduction pour pouvoir parser les résultats et appliquer les bons traitements).

++

Dernière modification par Jc (07-05-2012 20:12:09)

Maljuna Kris · 07-05-2012 20:25:02

Jc a écrit :

Maljuna Kris a écrit :
Puisque Jc n'est pas présent, pour le moment, je vais répondre, en partie, à tes objections.
Je suppose que tu as oublié tes lunettes

Non, c'est juste qu'à mon âge, on est plus lent. Quand j'ai commencé à rédiger mon post, tu n'avais pas encore posté le tien.

Maljuna Kris · 07-05-2012 20:29:58

Jc a écrit :

l'intérêt primaire d'une requête préparée est de pouvoir effectuer une même requête effectuée de multiples fois avec des paramètres différents.

Ce n'est pas tout à fait exact, disons, que c'est mal exprimé.
Les paramètres sont les mêmes, ce sont leurs valeurs qui peuvent changer d'un appel à l'autre de la requête.

Ceci dit, je n'ai pas d'avis tranché sur le sujet, par une sorte de psittacisme, je ne faisais que relayé les préconisations de la doc MySQL.

Jc · 08-05-2012 01:24:21

maljuna kris a écrit :

Les paramètres sont les mêmes, ce sont leurs valeurs qui peuvent changer d'un appel à l'autre de la requête.

Oui en effet, un petit moment d'égarement, autant pour moi

Jc · 10-05-2012 01:01:05

maljuna kris a écrit :

Non, c'est juste qu'à mon âge, on est plus lent. Quand j'ai commencé à rédiger mon post, tu n'avais pas encore posté le tien.

Vu que j'ai posté mon message à

forum a écrit :

07-05-2012 15:11:04

que je l'ai modifié à

forum a écrit :

Dernière modification par Jc (07-05-2012 15:58:03)

et que tu as posté ton message

forum a écrit :

07-05-2012 16:56:33

quand tu as dit que tu es lent, je pense que c'est un doux euphémisme sacré MK

Maljuna Kris · 10-05-2012 06:51:42

Jc a écrit :

quand tu as dit que tu es lent, je pense que c'est un doux euphémisme

Je crains, hélas, qu'il ne s'agisse que de la réalité. La décrépitude nous guette et mon pseudo, prémonitoire à cet égard, se vérifie chaque jour davantage.
C'est que je traîne, avec le poids des ans, celui des habitudes, bonnes et mauvaises qui, chacune, emporte son lot d'atermoiements dont se nourrit ma procrastination.
Je m'en console, parfois, en me remémorant la victoire de la tortue sur le lièvre, mais cette illusion fait long feu.
Dorénavant je suis, à la lettre, les préconisations de Nicolas Boileau

Travaillez à loisir, quelque ordre qui vous presse,
Et ne vous piquez point d'une folle vitesse
Un style si rapide, et qui court en rimant,
Marque moins trop d'esprit que peu de jugement.
J'aime mieux un ruisseau qui, sur la molle arène,
Dans un pré plein de fleurs lentement se promène,
Qu'un torrent débordé qui, d'un cours orageux,
Roule, plein de gravier, sur un terrain fangeux.
Hâtez-vous lentement, et, sans perdre courage,
Vingt fois sur le métier remettez votre ouvrage
Polissez-le sans cesse et le repolissez ;
Ajoutez quelquefois, et souvent effacez.

Au demeurant, sur mon clavier d'ordinateur, la touche SUPPR, au libellé à demi effacé, témoigne du grand usage que j'en aie.

PHP|Débutant :: Forums

Advertisement

#1 02-05-2012 02:59:24

Développement en SGBDR Epais - Introduction / Outils / Astuces

#2 02-05-2012 12:26:58

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#3 02-05-2012 13:13:39

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#4 02-05-2012 23:45:03

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#5 03-05-2012 06:40:01

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#6 04-05-2012 04:36:17

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#7 04-05-2012 07:30:16

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#8 07-05-2012 00:14:42

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#9 07-05-2012 14:11:04

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#10 07-05-2012 15:56:33

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#11 07-05-2012 19:33:59

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#12 07-05-2012 20:10:16

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#13 07-05-2012 20:25:02

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#14 07-05-2012 20:29:58

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#15 08-05-2012 01:24:21

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#16 10-05-2012 01:01:05

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

#17 10-05-2012 06:51:42

Re : Développement en SGBDR Epais - Introduction / Outils / Astuces

Pied de page des forums