Nouvel article : Migration Oracle ou SQL Server vers PosteGreSQL - les écueils

[SQLpro]

Au risque de mettre de l'huile sur le feu, je pourrais rajouter certains manques fonctionnels, qui peuvent être des détails, mais feront vite la différence pour certaines applications particulières :

• pas de "batch" (exécution d'un lot de commandes SQL)
• pas de vues indexées ou matérialisées
• un support des collations minimaliste avec lequel il est impossible de développer des applications multilingues.
• pas de DATALINK (norme SQL 1999) ou de FILESTREAM (équivalent MS SQL Server) pour stocker des fichiers sous le contrôle du SGBDR
• pas de déclencheurs DDL (CREATE, ALTER, DROP ... DATABASE, TABLE, INDEX, VIEW, PROCEDURE, FUNCTION....) très utiles pour automatiser des tâches d'admin ou du fonctionnel avancé
• pas d'indexation du XML
• pas de mise à jour XML
• pas d'outil de récupération des espaces morts (défragmentation physique)
• pas gestionnaire de ressources (exemple Resource Governor de SQL Server) pour limiter les ressources affectées à un utilisateur (par exemple lorsque le reporting est fait en live sur la base de production)
• pas snapshot de base de données (une photocopie d'une base entière à une heure précise)
• pas de mécanisme intégré de CDC (change data capture) comme je l'ai déjà mentionné (important pour effectuer des mise à jour différentiels de DataWarehouse)
• du fait de l'absence de hint, pas de "repères de plan" (SQL Server), c'est à dire la possibilité d'imposer à une requête que l'on ne peut pas modifier (venant par exemple d'un exécutable) un plan forcé
• pas de mécanisme de gestion de bases de données réparties transactionné et sérialisé (par exemple Service Broker de SQL Server), permettant par exemple de répartir les données à traiter sur une grille se serveurs SQL
• pas de "master data services" (workflow, règles d'affaires et mécanismes d'approbations / rejets pour qualifier les données de référence de l'entreprise)

Il y à d'autres manques, mais ils sont plus cosmétiques, comme l'absence de "politiques" de gestions (en gros des règles de bonne gestion que le DBA met en œuvre et dont il surveille de manière passive ou active l'application)

A +

[SQLpro]

Envoyé par JeitEmgie

Dès lors quelles sont les motivations pour taper inutilement sur PostgreSQL ?
Craindre que les gens qui investissent dans cet outil considèrent plus facilement ORACLE que MSQL-Server comme choix logique lorsque la nécessité s'en fera sentir ?

Voyez-vous votre réaction me navre... Je comprends que vous soyez passionné ! mais la passion et la raison ne font généralement pas bon ménage !
Pourquoi n'aurais-je pas le droit de critiquer, alors que presque tout le monde brosse PG dans le sens du poil ?
Et comme je suis un esprit libre, quand je voit tout le monde dire du bien d'un produit je me méfie en me disant qu'un produit parfait cela n'existe pas et que j'ai affaire soit à des gens incultes soit, ce qui est pire, à des gens de mauvaise foi.

Croyez vous qu'à 50 ans passé je soit encore adepte du consensus mou et du politiquement correcte ?

Analyser, comprendre, critiquer... C'est TOUJOURS positif ! C'est progresser.

Il n'y a guère que dans les régimes totalitarisme que la critique est interdite.
Et à lire certains internautes, je me suis demandé s'ils ne venaient pas de ce genre de contrées.

Et rassurer-vous, je commet aussi des erreurs... C'est pourquoi il ne faut pas croire tout ce que je dit sans tester par vous même la réalité des choses.

A +

[JeitEmgie]

Envoyé par SQLpro

Voyez-vous votre réaction me navre... Je comprends que vous soyez passionné ! mais la passion et la raison ne font généralement pas bon ménage !
Pourquoi n'aurais-je pas le droit de critiquer, alors que presque tout le monde brosse PG dans le sens du poil ?
Et comme je suis un esprit libre, quand je voit tout le monde dire du bien d'un produit je me méfie en me disant qu'un produit parfait cela n'existe pas et que j'ai affaire soit à des gens incultes soit, ce qui est pire, à des gens de mauvaise foi.

Croyez vous qu'à 50 ans passé je soit encore adepte du consensus mou et du politiquement correcte ?

Analyser, comprendre, critiquer... C'est TOUJOURS positif ! C'est progresser.

Il n'y a guère que dans les régimes totalitarisme que la critique est interdite.
Et à lire certains internautes, je me suis demandé s'ils ne venaient pas de ce genre de contrées.

Et rassurer-vous, je commet aussi des erreurs... C'est pourquoi il ne faut pas croire tout ce que je dit sans tester par vous même la réalité des choses.

A +

Ridicule : vous n'avez strictement rien compris à ma question !
Vous pouvez critiquer PostreSQL tant que vous voulez, je ne me sens pas concerné et ce n'est absolument pas la question que je pose :

vous abordez la question sous l'angle de la migration de DB2/ORACLE/SQL-Server vers PostgreSQL et ma question est

qui de sérieux cela intéresse-t-il ?

car de deux choses l'une :

ou les raisons qui ont prévalu au choix initial qui a amené à s'équiper en DB2/ORACLE/SQL-Server ont été l'aboutissement d'une analyse sérieuse,
et il n'y a aucune raison que ces bonnes motivations puissent être remises en question au point de "descendre" vers PostgreSQL (mieux faut convoquer le commercial de son vendeur SGBD et négocier ferme les coûts par rapport aux besoins réels…),

ou ses raisons n'étaient pas sérieuses et donc que penser du public concerné… (ou des rigolos ou des incompétents piégés par des commerciaux peu scrupuleux…)
Donc, tout cela ressemble plus à un exercice académique de br… intellectuelle qu'à autre chose.

Alors que la problématique contraire :
comment upgrader de PostgreSQL vers DB2/ORACLE/SQL-Server et quelles sont les bonnes méthodologies à appliquer pour que cela se passe en douceur est probablement susceptible d'intéresser beaucoup plus de monde, que ce soit pour un besoin réel dans une entreprise grandissante, une analyse de risques dans une start-up, ….

[punkoff]

toujours est-il que cet article permet d'avoir une base de comparaison des dit produits afin de mieux choisir une solution adaptée.

Alors peut-être qu'il a été mal amené mais je le trouve intéressant.

[SQLpro]

Envoyé par JeitEmgie

comment upgrader de PostgreSQL vers DB2/ORACLE/SQL-Server et quelles sont les bonnes méthodologies à appliquer pour que cela se passe en douceur est probablement susceptible d'intéresser beaucoup plus de monde, que ce soit pour un besoin réel dans une entreprise grandissante, une analyse de risques dans une start-up, ….

Non, les deux existent. De nombreuses entreprises se posent actuellement la question et depuis quelques années de plus en plus, du coût exorbitant des licences Oracle et tente de trouver des solutions autres, parmi lesquelles SQL Server, PostGreSQL et MySQL sont les plus souvent citées, même si MySQL est rarement retenu en final.

Donnant pas mal de formations notamment Admin SQL Server, je voit beaucoup de monde passer de Oracle à SQL Server ou PG.

Cette hémorragie a été confirmée par une récente étude sur les salaires moyens d'embauche des DBA qui a diminué pour Oracle et augmenté pour SQL Server. De même les demandes de personnel confirmés sur PG sont en évolution.

A +

[estofilo]

Envoyé par JeitEmgie

vous abordez la question sous l'angle de la migration de DB2/ORACLE/SQL-Server vers PostgreSQL et ma question est

qui de sérieux cela intéresse-t-il ?

Un exemple d'hier: un service des douanes qui cherche apparemment des consultants pour évaluer une migration d'Oracle vers Postgresql.
http://www.freelance-info.fr/offre-d...on_104337.html

On peut imaginer que la raison est de dépenser au final moins d'argent public, ce qui est une raison réelle et sérieuse et qui n'est pas prêt de disparaitre.

On peut aussi interpréter ça en regardant en arrière. Les SGBDs commerciaux par rapport aux libres ont une avance historique, car ce n'est qu'au milieu des années 90 que les libres ont commencé à vraiment se développer, quand le SQL s'est démocratisé en même temps que le développement exponentiel du web. A cette époque les produits commerciaux cités plus haut étaient déjà des produits matures et riches en fonctionnalités alors que les libres partaient de zéro.
En ce qui concerne postgresql, depuis ce temps là, version après version, les fonctionnalités manquantes ont tendance à faire leur apparition, les points noirs sur les performances sont identifiés et corrigés.
De leur côté les SGBDs commerciaux ont toujours de l'avance et progressent toujours aussi, mais l'écart relatif sur les points déterminants tend à diminuer.

[Arnaud B.]

+1

Quelque soit l'angle d'approche, cette comparaison est très intéressante.

Pour citer notre exemple, nous utilisons un SGBD qui ne nous convient pas pour certains usages, et nous nous posons la question de migrer vers PG, Oracle ou MS SQL : hé bien, cette discussion a permis d'avancer dans la réflexion.

Cdlt, Arnaud.

Envoyé par punkoff

toujours est-il que cet article permet d'avoir une base de comparaison des dit produits afin de mieux choisir une solution adaptée.

Alors peut-être qu'il a été mal amené mais je le trouve intéressant.

[Arnaud B.]

Envoyé par SQLpro

[*]pas de mécanisme intégré de CDC (change data capture) comme je l'ai déjà mentionné (important pour effectuer des mise à jour différentiels de DataWarehouse)

Bonsoir Frédéric, petite question : vous aviez écrit un article fin 2009 sur l'implémentation (manuelle) du CDC dans SQL Server.
Vu votre remarque (ci-dessus), j'en conclus que c'est désormais intégré en natif dans SQL Server ?

Cdlt, Arnaud.

[scheu]

Le problème quand on fait appel à un consultant pour étudier une migration de Oracle vers Postgresql, c'est que si le consultant est spécialisé Postgresql (je ne citerai pas de noms mais j'en connais), il connaît très peu les SGBDs payants, et va vous faire croire qu'on peut tout faire avec Postgresql, sans vous parler des limites (par exemple il va vous dire que le partitionnement ou l'optimiseur de requêtes sous Postgresql n'ont rien à envier à Oracle ou SQl Server, alors que c'est faux).
C'est seulement en posant les bonnes questions et en grattant un peu qu'il va finalement avouer à demi-mots que telle ou telle chose n'est pas encore faisable avec Postgresql

C'est cette démarche que je ne trouve pas toujours honnête, quand on écoute les gens qui connaissent bien Postgresql, on tombe vite dans l’extrémisme pro-opensource et anti SGBDs payants, alors que quand un SGBD est payant ce n'est pas seulement pour engraisser les commerciaux c'est aussi parce qu'ils ont des fonctionnalités supplémentaires ou moins de lacunes.

C'est pourquoi l'article de SQL Pro a au moins le mérite de parler des limites de Postgresql par rapport à un SGBD payant, libre à chacun ensuite d'évaluer si ces limites sont incompatibles ou non avec le besoin

[SQLpro]

Envoyé par Arnaud B.

Bonsoir Frédéric, petite question : vous aviez écrit un article fin 2009 sur l'implémentation (manuelle) du CDC dans SQL Server.
Vu votre remarque (ci-dessus), j'en conclus que c'est désormais intégré en natif dans SQL Server ?
Cdlt, Arnaud.

Oui, depuis le version 2008, SQL Server supporte deux modes de suivi du changement : Change Tracking et Change Data Capture.

Change Tracking indique pour chaque table suivi, l’opération (INSERT, UPDATE, DELETE) la clef, et la dateheure de l'opération.
Change Data Capture y ajoute les informations des lignes modifiées, mais n'est disponible que dans l'édition Enterprise.
La différence essentielle entre l'un et l'autre est qu'avec CDC on n'a pas besoin de faire des requêtes sur les tables de production car toute l'info est dans les tables de capture, mais en revanche le volume des informations stockées est plus important.

A +

[genemartin]

Pour les non spécialistes comme moi, simple utilisateur, tout ça ressemble à une discussion entre des aveugles et des sourds, chacun dégainant son arsenal d'arguments et c’est à qui sera plus spécialiste que l'autre.

Moi je reste muet, et dans le domaine dans lequel je travaille, les bases de données géospatiales, j'utilise tant Oracle Spatial que PostgreSQL/PostGIS

Je constate simplement que de plus en plus d'organismes, comme l'IGN France, ont choisi la solution PostGIS.
C'est le cas, notamment, du Geoportail IGN (Geoportail )qui a choisi et utilise PostGIS pour servir les données géographiques, après une sérieuse étude de marché.

IGN began exploring storing their data in a seamless database for the entire country around 2002. They benchmarked several technologies, including Oracle, DB2 and PostGIS/PostgreSQL, looking for a product that met a number of requirements:

• The capacity to handle more than 100 million spatial objects;
• The speed to answer queries quickly given such a large database; and,
• Full transactional integrity to ensure data quality during maintenance operations.

The benchmarking tests showed PostgreSQL/PostGIS with similar performance to the proprietary alternatives.

tiré de http://postgis.refractions.net/docum...sestudies/ign/

Même plus, l'IGN participe depuis lors au développement de PostGIS et est devenu un des sponsors de la "Fondation Géospatiale Open Source" (http://www.osgeo.org/).

Il y aura toujours des spécialistes d'un logiciel particulier, qui auront tendance à dénigrer ce qui se fait ailleurs. Mais soyons donc constructif. Oracle, PostgreSQL ou MySQL ne s'adressent ni au même public, ni aux mêmes domaines. Suivant les cas pratiques, on va choisir l'un ou l'autre.
Hormis exception, les grandes sociétés privilégieront toujours la solution propriétaire, payante, pensant à tord ou à raison, que le suivi sera meilleur.

Il est clair que l'aspect économique joue aussi. Si j'ai beaucoup de sous, ce sera Oracle, clé en main, si j'en ai ai peu, PostgreSQL ou MySQL, moins clé en main. Ne parlons pas des solutions NoSQL, sujet de discussions encore plus virulentes

Pour moi, c'est donc Oracle et PostgreSQL et non Oracle ou PostgreSQL, suivant les cas particuliers.

[SQLpro]

En ce qui concerne PostGIS vos documents datent terriblement. Entre temps l'IGN à commencé d'utiliser SQL Server. En effet, PostGIS ne sait pas utiliser proprement les SRID spécifique à chaque pays, comme je l'indique dans cette comparaison PostGIS/SQL Server 2008 GIS; Or pour les collectivités française il est fait obligation d'utiliser des SRID spécifiques à la France, en particulier :

Code :

1
2
3
4
5
6
7
8
9
10
spatial_reference_id well_known_text
-------------------- -----------------------------------------------------------------------------
4171                 GEOGCS["RGF93",     DATUM["Reseau Geodesique Francais 1993"
4624                 GEOGCS["RGFG95",    DATUM["Reseau Geodesique Francais Guyane 1995"
4640                 GEOGCS["RRAF 1991", DATUM["Reseau de Reference des Antilles Francaises 1991"
4687                 GEOGCS["RGPF",      DATUM["Reseau Geodesique de la Polynesie Francaise"
4965                 GEOGCS["RGF93",     DATUM["Reseau Geodesique Francais 1993"
4967                 GEOGCS["RGFG95",    DATUM["Reseau Geodesique Francais Guyane 1995"
4973                 GEOGCS["RRAF 1991", DATUM["Reseau de Reference des Antilles Francaises 1991"
4999                 GEOGCS["RGPF",      DATUM["Reseau Geodesique de la Polynesie Francaise"

Sinon, les calculs, notamment d'aires sont faussés.

Bref, rafraichissez vos données et ne croyez pas naïvement tout ce qui traîne sur Internet !

A +

[genemartin]

Je pense que votre position de spécialiste, de "Maître es Bases de données", donnant des leçons aux autres, même si c'est vrai, est néanmoins choquante pour un utilisateur lambda. Et pourtant j'apprécie énormément vos tutoriels.

Mais, j'ai essayé d'être constructif, mais en retour, je ne peux que constater diverses choses :

En tout premier :

Bref, rafraichissez vos données et ne croyez pas naïvement tout ce qui traîne sur Internet !

Croyez-vous que je sois c.. à ce point, après plus de 10 ans dans le domaine géospatial ?

Ensuite :

• je ne citais le cas de l'IGN français qu'à titre d'exemple. Je ne suis pas français et je n'ai pas besoin des projections françaises. Chez moi, PostGIS marche sans problème, de même qu'Oracle Spatial.
• d'après ce que m'ont dit des collègues géomaticiens français, l'IGN français propose des outils pour régler les problèmes (http://lambert93.ign.fr/index.php?id=30) et eux n'en ont pas. Depuis lors, les nouvelles versions de PostGIS ont rectifié le tir (grâce à l'IGN, et oui, ça évolue aussi..)
• l'IGN peut donc choisir de migrer vers TrucSQL ou MachinSQL, c'est le cadet de mes soucis, même si je l'ai lu "naivement" sur Internet (ici)
• je ne suis pas un "spécialiste" de base de données mais dans mon domaine, qui n'est pas la géomatique (je ne fais que l'utiliser), je n'ai pas cette attitude vis à vis de ceux qui le connaissent moins bien et essayent de le pratiquer.
• et donc, simple utilisateur de PostGIS et d'Oracle Spatial, je n'aurai plus l'outrecuidance d'émettre un avis ou de poser des questions, j'irai voir ailleurs (il y a d'autres forums sur le geospatial bien plus constructifs et respectueux vis à vis des utilisateurs,forums francophones, anglo-saxons ou espagnols).
• car, somme toute, à quoi ça sert de participer à un forum dédié à PostgreSQL, puisqu'un modérateur estime que ce n'est pas si bon que ça ou qu'on n'y connait rien... (votre réponse à Requête spatiale postGIS)
• En conséquence, je ne vois pas non plus l'intérêt d'un papier qui parle de migration de Rolls-Royces vers une 2 CV, l'inverse aurait été bien plus intéressant. Finalement j'aurais mieux fait de ne pas donner mon avis.
• mais tout ça n'est pas grave puisque je ne suis qu'un pauvre nunuche dans le domaine des Bases de données.
  

[MaitrePylos]

Bonjour,

Dimitri Fontaine SEO de 2ndQuadrant, Socièté spécialisé dans les outils PostgreSQL, nous propose un droit de réponse à l'article de Frédéric Brouard.


Droit de Réponse.

En vous remerciant tous de cet échange constructif.

MaitrePylos.

[CinePhil]

Droit de réponse bourré de pub mais qui a le mérite de ne pas être polémiste, en regard de ce qu'on a pu lire comme réactions par ailleurs.

[SQLpro]

Second Quadrant fait de la pub, certes, mais constructive en disant, effectivement il y a une lacune et nous nous pouvons la combler...
C'est honnête... reste le prix à payer !
Parfois le gratuit peut couter plus cher qu'on ne le croit...

A +

[MaitrePylos]

Envoyé par SQLpro

Parfois le gratuit peut couter plus cher qu'on ne le croit...

PostgreSQL n'est pas gratuit, il est Open source !

Open Source ne veut pas dire gratuit
Gratuit ne veut pas dire pour rien


On vient de renouveler nos licences Oracle et nous sommes à plusieurs millions d'euros (pour 4 ans) + un petit 20% pour la maintenance évolutive des 10G.

A ce prix là on aurais pu financer deux ou trois truc chez PostgreSQL, voire au moins faire jouer la concurrence..... mais comme on dit chez nous 'Oracle c'est prestigieux' (ça c'est de l'argument )

[scheu]

C'est de la publicité effectivement ... mais au moins en effet le discours est plus objectif et honnête

[SQLpro]

Envoyé par MaitrePylos

On vient de renouveler nos licences Oracle et nous sommes à plusieurs millions d'euros (pour 4 ans) + un petit 20% pour la maintenance évolutive des 10G.

A ce prix là on aurais pu financer deux ou trois truc chez PostgreSQL, voire au moins faire jouer la concurrence..... mais comme on dit chez nous 'Oracle c'est prestigieux' (ça c'est de l'argument )

Même constat pour certains de mes clients du monde MS... Mais il faut aussi intégrer dans ce coût la formation. Un bon développeur SQL Server ou Oracle, c'est devenu rare et ça coute cher et plus encore pour un DBA !
C'est le poids d'une migration et la sagesse du coût global, beaucoup plus sensible en matière de SGBDR du fait de l'inertie des données....

A +

[SQLpro]

Un petit exemple du manque crucial de tag (indicateur pour l'optimiseur) dans les requêtes complexes... :

A +