Comments on: Les bases de données épaisses http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297 Ressources sur le développement internet, PHP/MySQL, Ajax, marketing online, référencement... Thu, 17 Jun 2010 18:09:04 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Mazzu http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1116 Mazzu Tue, 04 Aug 2009 02:45:16 +0000 http://www.php-experts.org/?p=297#comment-1116 Quelqu'un connaitrait il le nom anglais du concept de base de données épaisses ? Quelqu’un connaitrait il le nom anglais du concept de base de données épaisses ?

]]> By: Hawat http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1100 Hawat Mon, 27 Jul 2009 12:07:17 +0000 http://www.php-experts.org/?p=297#comment-1100 Le "concept" de "bases de données épaisses" est proprement idiot. Il va a l'encontre de maints principes fondamentaux de developpements propre et moderne. Bien entendu, pour certains cas particulies ou meme pour un jeune developeur naif ca pourrait paretre allechant. Par "naif", il faut entendre sans comprehension profonde des modeles existants. Cela ne sous entends pas, par exemple, comprendre le fonctionnement de MVC/MVC2 mais plutot pourquoi nous en sommes arrive a ces conclusions. Sinon vous vous condamnez a repasser par les chemins qui ont ammene la. Le modele de developpement en couches a une raison d'etre autre que theorique! La "bases de données épaisses" va a l'encontre meme du principe de separation des roles. Un projet empruntant ce chemin, sur le long terme, arrivera sans l'ombre d'un doute a un spagetti difficilement maintenable et/ou evolutif. Le “concept” de “bases de données épaisses” est proprement idiot.
Il va a l’encontre de maints principes fondamentaux de developpements propre et moderne.

Bien entendu, pour certains cas particulies ou meme pour un jeune developeur naif ca pourrait paretre allechant.

Par “naif”, il faut entendre sans comprehension profonde des modeles existants.
Cela ne sous entends pas, par exemple, comprendre le fonctionnement de MVC/MVC2 mais plutot pourquoi nous en sommes arrive a ces conclusions.
Sinon vous vous condamnez a repasser par les chemins qui ont ammene la.

Le modele de developpement en couches a une raison d’etre autre que theorique!

La “bases de données épaisses” va a l’encontre meme du principe de separation des roles.
Un projet empruntant ce chemin, sur le long terme, arrivera sans l’ombre d’un doute a un spagetti difficilement maintenable et/ou evolutif.

]]> By: Clochix http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1094 Clochix Tue, 14 Jul 2009 20:41:09 +0000 http://www.php-experts.org/?p=297#comment-1094 Merci de m'avoir signalé cet excellent article de Frédéric Brouard. Un de ses mérites est de mettre en évidence le fossé entre les développeurs qui ont une culture du développement web et ceux de l'"industrie". Pour les seconds, la question de la portabilité de la base de donnée ne se pose pas. Il n'existe qu'un très petit nombre de SGBD "sérieux", et le choix de l'un d'eux par une entreprise est un des fondements les plus intangibles de sa culture informatique. Chez Machin, on utilise Oracle depuis toujours et personne n'imagine une seconde utiliser une autre base. La base change moins vite que les langages utilisés pour réaliser les interfaces. Dès lors, il est naturel d'exploiter au maximum les possibilités du SGBD. De l'autre côté, dans le monde du web, beaucoup de développeurs ne connaissent que des outils "gadget", comme PHP et MySQL. Vu les faibles possibilités de ce dernier, on a pris l'habitude de ne considérer les bases de données que comme de simples entrepôts de stockage, interchangeables. Il y a là deux cultures très éloignées. Mais je ne crois pas que l'une ou l'autre l'emporte un jour. Elles ne jouent pas dans la même cours de récréation. La majorité des applications web sont de toute façon des trucs jetables pour lesquels il n'est pas nécessaire d'investir en développements sérieux. Merci de m’avoir signalé cet excellent article de Frédéric Brouard. Un de ses mérites est de mettre en évidence le fossé entre les développeurs qui ont une culture du développement web et ceux de l’”industrie”. Pour les seconds, la question de la portabilité de la base de donnée ne se pose pas. Il n’existe qu’un très petit nombre de SGBD “sérieux”, et le choix de l’un d’eux par une entreprise est un des fondements les plus intangibles de sa culture informatique. Chez Machin, on utilise Oracle depuis toujours et personne n’imagine une seconde utiliser une autre base. La base change moins vite que les langages utilisés pour réaliser les interfaces. Dès lors, il est naturel d’exploiter au maximum les possibilités du SGBD. De l’autre côté, dans le monde du web, beaucoup de développeurs ne connaissent que des outils “gadget”, comme PHP et MySQL. Vu les faibles possibilités de ce dernier, on a pris l’habitude de ne considérer les bases de données que comme de simples entrepôts de stockage, interchangeables.

Il y a là deux cultures très éloignées. Mais je ne crois pas que l’une ou l’autre l’emporte un jour. Elles ne jouent pas dans la même cours de récréation. La majorité des applications web sont de toute façon des trucs jetables pour lesquels il n’est pas nécessaire d’investir en développements sérieux.

]]> By: desfrenes http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1093 desfrenes Mon, 13 Jul 2009 15:28:59 +0000 http://www.php-experts.org/?p=297#comment-1093 "Outre le fait qu’on obtient une application plus facilement portable" Ah ? parce que maintenant les procédures stockées sont portables d'un SGBDR à l'autre (enfin... pour ceux qui les supportent !) d'un claquement de doigt ? “Outre le fait qu’on obtient une application plus facilement portable”

Ah ? parce que maintenant les procédures stockées sont portables d’un SGBDR à l’autre (enfin… pour ceux qui les supportent !) d’un claquement de doigt ?

]]> By: PaT http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1090 PaT Mon, 13 Jul 2009 13:26:03 +0000 http://www.php-experts.org/?p=297#comment-1090 Je suis 100% d’accord! Les développeurs ont souvent la mauvaise habitude de tout centraliser au niveau du code. Résultat: un serveur web abusivement sollicité et un serveur MySQL idle. Il faut savoir répartir équitablement la charge, et dans quelle circonstance il est préférable de le faire. Non seulement on y gagne en performance, mais aussi une validation d'intégrité quant à la logique métier à respecter. Je trouve un peu exagéré de "tuer" les ORM. Ils sont bien et ils accélèrent le développement d'une application, mais il faut bien comprendre les limites! Ils ne sont pas conçus par exemple pour produire un rapport financier qui doit agréger plusieurs données. Je suis 100% d’accord! Les développeurs ont souvent la mauvaise habitude de tout centraliser au niveau du code. Résultat: un serveur web abusivement sollicité et un serveur MySQL idle.

Il faut savoir répartir équitablement la charge, et dans quelle circonstance il est préférable de le faire. Non seulement on y gagne en performance, mais aussi une validation d’intégrité quant à la logique métier à respecter.

Je trouve un peu exagéré de “tuer” les ORM. Ils sont bien et ils accélèrent le développement d’une application, mais il faut bien comprendre les limites! Ils ne sont pas conçus par exemple pour produire un rapport financier qui doit agréger plusieurs données.

]]> By: Mat http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1089 Mat Mon, 13 Jul 2009 10:26:29 +0000 http://www.php-experts.org/?p=297#comment-1089 Personnellement, je préfère déporter la majeur partie des calculs sur la partie web/front que sur la base de donnée. Il est bien plus facile de rendre scalable un serveur web (en faisant un cluster load-balancé) plutot qu'une base de données (sharding, réplication avec read/write balancing, quoi qu'il arrive il y a un gros travail à effectuer coté applicatif). Personnellement, je préfère déporter la majeur partie des calculs sur la partie web/front que sur la base de donnée.

Il est bien plus facile de rendre scalable un serveur web (en faisant un cluster load-balancé) plutot qu’une base de données (sharding, réplication avec read/write balancing, quoi qu’il arrive il y a un gros travail à effectuer coté applicatif).

]]> By: Olivier Mansour http://www.php-experts.org/bases-de-donnees/mysql/les-bases-de-donnees-epaisses-297/comment-page-1#comment-1088 Olivier Mansour Mon, 13 Jul 2009 09:31:22 +0000 http://www.php-experts.org/?p=297#comment-1088 C'est bien sur évident du point de vue de la performance et pas nouveau du tout. Ca marche bien pour des traitements simple faisable dans le SELECT de la requete. Par contre, disperser plus sa logique métier est contre productif selon moi : http://www.glagla.org/weblog/2007/05/16/trigger-ou-pas-trigger/ C’est bien sur évident du point de vue de la performance et pas nouveau du tout. Ca marche bien pour des traitements simple faisable dans le SELECT de la requete.

Par contre, disperser plus sa logique métier est contre productif selon moi : http://www.glagla.org/weblog/2007/05/16/trigger-ou-pas-trigger/

]]>