Je suis assez d'accord avec toi, mais pas avec ta manière de le présenter ;-)
La plupart des entreprises pourraient migrer vers PostgreSQL car elles ont des bases à volumétries faibles (bien souvent < 100 Go), peu de trafic et peu de concurrence ;-)
Les options de stockage, sauvegardes, chiffrement, partitionnement doublent voire quadruplent rapidement le prix du moteur Oracle, de l'intérêt d'utiliser un logiciel libre où les fonctionnalités ne sont pas bridées lorsqu'elles arrivent enfin à maturité ou deviennent enfin utilisables (je peux donner des exemples…). C'est justement le coût (et leur complexité de mise en œuvre) qui fait qu'elle sont justement peu souvent utilisées en réalité.
Peu de produits utilisent réellement les fonctions avancées de ce que j'en ai vu (ou en tout cas leur mise en œuvre n'a pas été prévue initialement et cela réclame plus d'intégration que simplement "activer" la fonctionnalité).
pour le hint sur les requêtes :
cela se voyait beaucoup en Oracle 7, il a fallu tout refaire en Oracle 8 (pas trop au passage en 9 iirc…),
beaucoup de migration en 10 ont échoué à cause du changement de moteur et régressions monstrueuses sur les performances,
le passage de Oracle 10 à 11 a l'air moins catastrophique déjà de ce que j'ai pu en voir (moins de cas, néanmoins…).
Donc bon, quitte à réécrire les requêtes, dans ce cas autant les réoptimiser pour PostgreSQL, il y a les plans d'exécution pour cela.
pour les pools de connexion (lorsqu'ils sont utilisés…)
d'une part il n'y en a pas forcément besoin (bon, je n'ai qu'un exemple de migration PostgreSQL vers Oracle, qui n'en utilisait pas initialement et où c'est devenu obligatoire, visiblement à cause d'Oracle vu que ça tenait la charge pour 300 utilisateurs connectés auparavant avec un tomcat/PostgreSQL mais pas avec JBoss/Oracle dès 50 utilisateurs connectés…)
c'est une option payante d'Oracle (elle double le prix du moteur)
de ce que je vois sur http://docs.postgresqlfr.org/9.1/ddl-partitioning.html cela correspond à ce qui peut être mis en œuvre côté Oracle (surtout du partitionnement par date pour historiser plus facilement et gérer les grosses volumétries… je l'ai rarement vu ailleurs que sur des bases de datawarehouse)
Bien sûr, d'un point de vue migration, pour démarrer, autant choisir les petites bases ne nécessitant pas réellement Oracle (pas de développement spécifique PL/SQL, pas de fonctionnalité ésotérique ou d'adhérence à une fonctionnalité spécifique d'Oracle), soit avec des développements internes maîtrisés soit avec des produits gérant déjà plusieurs types de bases si l'éditeur est prêt à faire le support aussi pour PostgreSQL, cet outil de migration servira pour les développements/tables spécifiques ajoutés (vu qu'il y en a souvent…). Cela permettra de voir l'ampleur des nombres d'instances créées ne nécessitant pas réellement Oracle et se faire la main sur des projets dont le fonctionnement est connu et faire monter en compétence l'équipe de DBA sur un nouveau moteur, avec ses particularités.
[^] # Re: question bête
Posté par BAud (site web personnel) . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 9.
Je suis assez d'accord avec toi, mais pas avec ta manière de le présenter ;-)
La plupart des entreprises pourraient migrer vers PostgreSQL car elles ont des bases à volumétries faibles (bien souvent < 100 Go), peu de trafic et peu de concurrence ;-)
Les options de stockage, sauvegardes, chiffrement, partitionnement doublent voire quadruplent rapidement le prix du moteur Oracle, de l'intérêt d'utiliser un logiciel libre où les fonctionnalités ne sont pas bridées lorsqu'elles arrivent enfin à maturité ou deviennent enfin utilisables (je peux donner des exemples…). C'est justement le coût (et leur complexité de mise en œuvre) qui fait qu'elle sont justement peu souvent utilisées en réalité.
Peu de produits utilisent réellement les fonctions avancées de ce que j'en ai vu (ou en tout cas leur mise en œuvre n'a pas été prévue initialement et cela réclame plus d'intégration que simplement "activer" la fonctionnalité).
Bien sûr, d'un point de vue migration, pour démarrer, autant choisir les petites bases ne nécessitant pas réellement Oracle (pas de développement spécifique PL/SQL, pas de fonctionnalité ésotérique ou d'adhérence à une fonctionnalité spécifique d'Oracle), soit avec des développements internes maîtrisés soit avec des produits gérant déjà plusieurs types de bases si l'éditeur est prêt à faire le support aussi pour PostgreSQL, cet outil de migration servira pour les développements/tables spécifiques ajoutés (vu qu'il y en a souvent…). Cela permettra de voir l'ampleur des nombres d'instances créées ne nécessitant pas réellement Oracle et se faire la main sur des projets dont le fonctionnement est connu et faire monter en compétence l'équipe de DBA sur un nouveau moteur, avec ses particularités.