Bonjour/soir,

que pensez vous de ceci

pour ma part je mettrai bien d'avantage de code métier dans des proc/triggers pour que "la charge" soit gérer par la base plutôt que le serveur web, qu'en dites vous ?

cdt.

Hello,

j'ai lu attentivement la chose, et oui, c'est très intéressant et n'a en gros que des avantages. C'est vrai qu'aujourd'hui, moi le premier, on utilise principalement les BDD parce que c'est pratique pour faire du stockage, on fait 2-3 jointures et basta (j'imagine que certains font bcp plus, mais est-ce la majorité ?).

Les limites que je peux voir dans les recommandations de l'article :

mysql, sans doute la db la plus populaire, ne supporte pas des choses qui me semble essentielles à l'application de ce modèle:

• l'insertion/la mise à jour des vues, sauf à partir de la v5.1 et avec une série de limitations
• pas de triggers "INSTEAD OF" pour faire des insert/updates complexes sur plusieurs tables via des procédures stockées

C'est dommage, car c'est selon moi les 2 points très intéressants de l'article, et qui notamment permettraient d'avoir un truc très puissant sans modifier jDao (pour les insert/update multi-tables par exemple) puisqu'on interrogerait que des vues.

Le problème plus général, c'est en fait de savoir sur quelle bdd doit pouvoir tourner l'appli que l'on produit (je parle en général, pas spécifiquement jelix). Aujourd'hui, vouloir faire un projet php opensource sans supporter mysql et imaginer le diffuser à plus ou moins grande échelle, j'y crois plus que moyennement (cf. les parcs des hébergeurs).

Il y a aussi le problème de la compétence en SQL qui me semble plus rare qu'en PHP par exemple (c'est un point soulevé dans l'article). C'est vrai pour le côté contributions, mais aussi je crois en (auto)formation que celà peut nécessiter.

Bon, assez de côtés négatifs, je persiste à dire que c'est sans doute la voie à suivre dès que le parc de DBB installé le permettra :

• on code moins au niveau applicatif
• en tapant directement dans la base avec le client en ligne de commande par exemple, les traitements complexes sont effectués indépendamment de l'appli (pratique pour de la maintenance à distance).
• si plusieurs applis différentes accèdent à la base, on est sur que les opérations sont traitées de la même façon.
• on a normalement plus à tenir compte des spécificités des bases au niveau applicatif (par exemple, je suis il y a quelques mois devenu fou en voulant porter une appli jelix sur du sqlite et j'avais des insert/updatepattern = NOW() dans mes dao. Et ben sqlite il connait pas now() ;) Alors certes, c'est possible de déclarer une fonction now dans la base, mais bon, ça surprend quand même...).

Bref, j'ai un gros projet à réaliser en environnement maîtrisé pour le côté serveur, je me demande si je vais pas essayer de mettre ça en pratique du postgres. Si c'est le cas, je vous tiendrais au courant de la façon dont jelix peut fonctionner sur ce plan.

Salut,

bon, j'avais répondu par mail à foxmask parce qu'il m'avait poser la même question par mail. Voici ma réponse, qui n'est pas très éloignée de celle de Julien.

je n'ai pas lu le pdf, mais bien sûr, oui, c'est bien plus sain de mettre des proc/triggers sur la base de donnée. C'est la garantie que quelque soit l'application qui attaque la base (dans une grosse boite, il arrive que la base servent à plusieurs applis differentes), les rêgles metiers soient respectées, et que si une rêgle change, que le code des applis soit moins impacté.

Le souci est que toutes les bases, jusqu'à peu (mysql 5), ne proposaient pas de proc/triggers. On avait alors un souci de portabilité, d'où l'habitude qu'ont pris les développeurs web de mettre le code coté appli. Sans parler du fait que beaucoup ne veulent utiliser qu'un langage (php par ex), et n'aiment pas toujours SQL.

Un autre souci conçernant la portabilité, et qui est toujours vrai de nos jours : la manière de coder les procedures stockées est différente selon les bases. Cela oblige donc à redévelopper les procédures autant de fois que le nombre de base que l'on veut supporter. Cela multiplie alors les bugs potentiels. Et puis, il n'est pas dit que toutes les bases proposent les mêmes fonctions, donc qu'on puisse porter les procédures d'une base à une autre...

Bref, d'un point de vue pragmatique, je dirais :

• pour une appli intranet, avec pour cible uniquement un type de base précis, proc/triggers, c'est à utiliser bien sûr. ça apporte plus de cohérence au modèle de donnée, et c'est plus performant.

• pour une appli publique comme ton forum, c'est à éviter je pense. Ou alors tu ne livre que pour une base précise, et dans ce cas, peut-être tu te coupera de certains utilisateurs, même si tu choisi mysql.. (t'en aura toujours un qui viendra se plaindre parce que ça marche pas sur sa base préférée).

Bref, c'est selon le cas, et le temps que l'on veuille bien y consacrer.