D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio ,ドル au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 5.
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio ,ドル au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.