Je suis d'accord avec toi, mais souvent la competence applicative n'est pas chez les DBA, qui en plus sont moins nombreux que les développeurs (et plus chers).
Enfin techniquement, mettre les fonctions applicatives dans les bases de données fini par bouffer de la performance sur la DB et les licenses (ok sur les DB commerciales ...) se paient au nombre de cores utilisés sur le serveur de DB...
J'ajoute que pour le stockage, multiplier les serveurs de DB coute aussi pas mal de fric.
Donc que faire ?
Utiliser la fameuse mode du n-tiers, et mettre un front-end java sur un serveur applicatif pour heberger le code applicatif sous forme de fonctions, publiée en SOAP par exemple.
Ces fonctions SOAP concentrent les appels aux DB (donc y'en a pas partout dans toutes les applis), le SOAP c'est gratuit (java + tomcat / jboss), et cela permet (comme les proc stockées) de rendre les fonctions disponibles pour toutes les applis de l'entreprise.
En bonus, SOAP est un protocole normalisé et disponible sur toutes les plateformes, dans tous les langages (pas la peine de déployer des connecteurs JDBC/ODBC/....)
Mais je suis d'accord avec toi, les proc stockées c'est bien, y'a juste des contrainte en entreprise qui font que d'autres solutions peuvent être préférées.
[^] # Re: PostgreSQL oui mais pas tout de suite
Posté par PLuG . En réponse à la dépêche Sortie de PostgreSQL 8.3. Évalué à 3.
Enfin techniquement, mettre les fonctions applicatives dans les bases de données fini par bouffer de la performance sur la DB et les licenses (ok sur les DB commerciales ...) se paient au nombre de cores utilisés sur le serveur de DB...
J'ajoute que pour le stockage, multiplier les serveurs de DB coute aussi pas mal de fric.
Donc que faire ?
Utiliser la fameuse mode du n-tiers, et mettre un front-end java sur un serveur applicatif pour heberger le code applicatif sous forme de fonctions, publiée en SOAP par exemple.
Ces fonctions SOAP concentrent les appels aux DB (donc y'en a pas partout dans toutes les applis), le SOAP c'est gratuit (java + tomcat / jboss), et cela permet (comme les proc stockées) de rendre les fonctions disponibles pour toutes les applis de l'entreprise.
En bonus, SOAP est un protocole normalisé et disponible sur toutes les plateformes, dans tous les langages (pas la peine de déployer des connecteurs JDBC/ODBC/....)
Mais je suis d'accord avec toi, les proc stockées c'est bien, y'a juste des contrainte en entreprise qui font que d'autres solutions peuvent être préférées.