PHP|Débutant :: Forums

Waouh, tu sais MK, je m'interesse à l'informatique depuis l'âge de 11ans, et la première chose qui m'a interressé et passionné sont les bases de données. C'est la première chose que j'ai comprise intuitivement et naturellement: que c'est la base de tout. C'était l'époque des fichiers à accès séquentiel et aléatoire, la base.
Lecture très enrichissante pour moi, car j'ai tendance à développer au niveau 3 (cf. le document joint page 5) (bien que la notion de client lourd que j'emploie diffère de celle qui y est entendue), et tout simplement parce que je maîtrise encore mal les vues et les triggers. Mais je pense que ce document m'a donné les éléments qui me manquaient pour les mettre en oeuvre, je pense. Je travaille en ce moment arduement sur les procédures stockées (ça fait pas mal de temps déjà). Je pense que dans moins d'un an j'aurais bouclé la boucle niveau SGBDR.

Une fois, (il n'y as pas si longtemps) un informaticien m'a demandé de lui finaliser son application. Il est allé voir ailleurs car je lui est dit que son appli était une coquille vide, qu'il n'y avait rien, que tout était et restait à faire. Comme je lui ai dit "certes, l'interface est faite, et tout ce qui a été fait représente un travail certain de l'argent et pas mal de temps", mais c'est que de la poudre aux yeux, il n'y a rien derrière. Et tout comme ce Monsieur, très peu réalisent en fait, que la fonctionnalité d'un module applicatif réside dans le développement de la requête qui le gère et pas ailleurs. Alors cela ne représente guère de code, ça à l'air de rien en apparence, mais tout y réside et cela fait toute la différence...

Merci encore pour ce lien, ça m'a fait bien plaisir en tout cas .

++

Dernière modification par Jc (28-11-2011 06:05:35)

Le problème commercialement parlant, c'est que lorsque l'on pense ainsi et que l'on a pas de certification au niveau SGBDR, on est plus souvent pris pour un farfelu qu'autre chose et cela n'aide pas vraiment à gagner sa vie. C'est bien pour cela que j'y travaille, mais faut ramer...
Il est vrai que si l'on devait parler d'application idéale, le papier de SQLpro le représenterait bien je pense. Or dans la réalité qu'est la nôtre dans l'utilisation qui est faite dans la pratique des logiciels web/cloud au quotidien, force est de constater que les applications ne sont pas utilisées on premise mais en remote, et cette réalité du client distant rend difficilement optimisable la notion de développement fin fin epais (type 6 p5) surtout quand on est soucieux de la qualité de l'expérience utilisateur qui nécessite un client "lourd" en termes de richesse d'interface (d'où la notion évoquée de "epais" fin épais précedemment). Avec du recul, et même en optimisant l'aspect vue et triggers côté serveur, plus j'y pense plus je reste convaincu que je me trompe pas dans mes modèles applicatifs web/cloud. J'ai lu pour la première fois un papier récemment d'un américain bardé de diplômes de surcroit, qui partage dans les grandes lignes ma vision du logiciel web/cloud tel qui devrait être (il y a quelques petites divergences tout de même), c'est en quelque sorte une sorte d'application composite de type "vertical" (process) dont la partie SGBDR est intégrée à la façon de M. Brouard et s'interfaçant avec l'extérieur via des webservices (+REST et d'autres flux) pour le contexte cloud. Dans un contexte web non cloud, l'aspect webservice reste moins performant et nécessite à mon humble avis d'autres optimisations dont l'objet ne fait pas partie de ce post .

Voilà pour l'essentiel.

++

Dernière modification par Jc (28-11-2011 11:39:06)