Discussion :

[KiLVaiDeN]

Bonjour,

J'ai le souhait de réaliser une application internet. Le langage est non défini pour l'instant, disons PHP ou JSP/Servlet/EJB. Le but de cette application est de concurrencer d'autres applications existantes sur le marché, et sans dévoiler le secteur qui m'interesse, le but est de proposer une application plus rapide et supportant une plus grosse montée en charge que les applications déjà existantes.

Pour ma problématique, prenons un exemple, la concaténation : Est-il plus rapide de la faire directement dans le SELECT en retournant la ligne concatenée, ou plutôt de la faire sur le serveur d'application en concatenant les colonnes retournées par le SELECT ? Je ne parle pas encore de problèmes de charge, il est évident que dans un cas, la base de données travaillera plus.

Est-ce que faire une procédure complexe sur le serveur de bdd est plus rapide de faire le même traitement coté serveur d'application ?

Est-ce qu'il y a des bases de données plus performantes aux niveau traitements que d'autres ? Par exemple, comment se compare MySQL à Oracle, en ce qui concerne la concaténation massive ?

Finalement, est-ce que les bdd ont un système de cache suffisament performant pour optimiser les traitements du style concaténation si ils sont demandés à de nombreuses reprises ? Y-a-t'il des différences à ce niveau là entre les différentes base de données du marché ?

J'ai l'impression ( peut-être fausse ) que les bases de données peuvent faire des traitements beaucoup plus rapidement que les serveurs d'applications dans presque tous les cas. Je compte donc faire un maximum de traitement du coté de la bdd, et décharger au maximum le serveur d'application, pensez-vous que cette orientation est valable, selon votre expérience ?

Merci d'avance,
K

[ddams]

Je compte donc faire un maximum de traitement du coté de la bdd, et décharger au maximum le serveur d'application, pensez-vous que cette orientation est valable, selon votre expérience ?

Pour ma part, je pense que positionner les traitements sur le serveur de base de données apporte très souvent un gain de performance. De plus, de cette manière on élimine beaucoup de code des pages : on obtient ainsi un appli propre et très maintenable.

Cependant cette solution a souvent un inconvénient majeur : La portabilité de l'appli sur un autre SGBD. En fonction, de tes traitements et des fonctions utilisées dans les procédures stockées et requêtes celà peut devenir assez galère.

[al1_24]

Cependant cette solution a souvent un inconvénient majeur : La portabilité de l'appli sur un autre SGBD. En fonction, de tes traitements et des fonctions utilisées dans les procédures stockées et requêtes celà peut devenir assez galère.

En effet, et le plus sur est alors de coder ses requêtes et procédures en SQL standard, en évitant toutes les extensions propres au SGBD utilisé.
C'est quelquefois un peu plus lourd mais toujours plus économique quand on change de SGBD (expérience : Interbase -> Oracle -> DB2 puis choix du SGBD à l'installation).