<aparté>
Tiens, pour une fois frecilia je suis plutot de ton avis !
</aparté>
par contre, dans tes Notes, je voudrais causer du <1>:
l'optimiseur Oracle (comme ses concurrents) a ses préferences. Du coup un type habitué a Oracle sait écrire les requetes dans le "bon ordre" pour que Oracle soit performant. C'est de moins en moins vrai (surtout depuis la v8) mais avant je te promet que changer l'ordre d'une clause pouvait avoir des répercussions assez fantastiques.
et puis du <2>: l'index a un cout lors des ecritures. Avoir des index sur plusieurs colonnes de plusieurs tables c'est cher, surtout si c'est pour optimiser une requete qui ne sert qu'une seule fois et encore pour un batch (j'exagere). C'est le probleme de toute optimisation: est-elle necessaire ?
enfin a propos du "drop column", ca me parait assez bidouille ton truc. Normalement on prevoit le schema de la base avant de la créer. Ensuite on developpe sur un serveur de ... developpement. Quand je m'y interessais, on avait des scritps pour re-creéer la base avec des données bidon que l'on pouvait relancer a volonté puisque pas en prod (je faisais des bench de requetes en oracle 8.0.5). Bref le "drop column" ca doit etre bien bas dans la liste des developpements necessaires sur postgresql, ce qu'il faut améliorer c'est plutot l'import/export et la réplication en live
(a mon avis mais je le partage avec vous :-))
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par PLuG . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 5.
Tiens, pour une fois frecilia je suis plutot de ton avis !
</aparté>
par contre, dans tes Notes, je voudrais causer du <1>:
l'optimiseur Oracle (comme ses concurrents) a ses préferences. Du coup un type habitué a Oracle sait écrire les requetes dans le "bon ordre" pour que Oracle soit performant. C'est de moins en moins vrai (surtout depuis la v8) mais avant je te promet que changer l'ordre d'une clause pouvait avoir des répercussions assez fantastiques.
et puis du <2>: l'index a un cout lors des ecritures. Avoir des index sur plusieurs colonnes de plusieurs tables c'est cher, surtout si c'est pour optimiser une requete qui ne sert qu'une seule fois et encore pour un batch (j'exagere). C'est le probleme de toute optimisation: est-elle necessaire ?
enfin a propos du "drop column", ca me parait assez bidouille ton truc. Normalement on prevoit le schema de la base avant de la créer. Ensuite on developpe sur un serveur de ... developpement. Quand je m'y interessais, on avait des scritps pour re-creéer la base avec des données bidon que l'on pouvait relancer a volonté puisque pas en prod (je faisais des bench de requetes en oracle 8.0.5). Bref le "drop column" ca doit etre bien bas dans la liste des developpements necessaires sur postgresql, ce qu'il faut améliorer c'est plutot l'import/export et la réplication en live
(a mon avis mais je le partage avec vous :-))