Tu as PostgreSQL qui suffirait largement la plupart du temps
J'imagine que c'est une façon de parler, mais les cas ou PostgreSQL ne suffit pas commencent franchement à se compter sur les doigts de la main d'un manchot.
En geospatial le couple PostGIS/QGIS avec éventuellement GRASS n'a plus grand chose à envier à ArcGIS sur Oracle Spatial. Et si vraiment les quelques outils ArcGIS qui manquent encore à PostGIS sont nécessaires, on peut l'installer sur PostGIS aujourd'hui.
En maintenance/sauvegarde/migration/montée de version, les outils Postgres sont désormais devant les outils Oracle à mon sens. 2nd Quadrant, Entreprise DB et Dalibo ont fait un boulot fantastique au cours des dernières années.
En liaison avec des DB extérieures et fonctionnalités ETL, Postgresql met une pile à Oracle depuis l'arrivée des Foreign Data Wrapper. Et c'est pas l'arrivée de la 9.5 avec les import automatiques de schémas qui va arrangé les chose. Essayez Multicorn...
En granularité des droits : On a pas encore les privilèges par colonne (mais ça arrive en 9.5), mais sinon les réécritures dynamiques de requêtes ou les tables fonctionnelles permettent de limiter grandement les éléments accédés par un utilisateur. Personnellement je préfère - mais ça demande un peu plus de dev.
En ce qui concerne les framework de développement rapide : MWAHAHAHA ... Désolé, j'ai pas pu m'en empécher.
Le dernier point ou Oracle a encore un gros avantage sur PostgreSQL c'est sur les clusters actifs/actifs pour des bases de données de plusieurs Go (voire To) sur lesquelles aucun partitionnement n'est raisonnablement envisageable. Mais déjà ça se réduit à chaque version, et ensuite dans le pire des cas il suffit souvent de faire appel à Entreprise DB (ou plus rarement à Citus si vraiment les besoins en I/O sont très élevé) pour résoudre le problème avec un cout de licence sans commune mesure avec Oracle.
[^] # Re: Don't be evil
Posté par Kaane . En réponse au journal Petite prévision pour l'avenir. Oracle !. Évalué à 10.
Tu as PostgreSQL qui suffirait largement la plupart du temps
J'imagine que c'est une façon de parler, mais les cas ou PostgreSQL ne suffit pas commencent franchement à se compter sur les doigts de la main d'un manchot.
En analyse statistique le cstore_fdw https://github.com/citusdata/cstore_fdw est tout simplement bluffant d'efficacité.
En geospatial le couple PostGIS/QGIS avec éventuellement GRASS n'a plus grand chose à envier à ArcGIS sur Oracle Spatial. Et si vraiment les quelques outils ArcGIS qui manquent encore à PostGIS sont nécessaires, on peut l'installer sur PostGIS aujourd'hui.
En maintenance/sauvegarde/migration/montée de version, les outils Postgres sont désormais devant les outils Oracle à mon sens. 2nd Quadrant, Entreprise DB et Dalibo ont fait un boulot fantastique au cours des dernières années.
En liaison avec des DB extérieures et fonctionnalités ETL, Postgresql met une pile à Oracle depuis l'arrivée des Foreign Data Wrapper. Et c'est pas l'arrivée de la 9.5 avec les import automatiques de schémas qui va arrangé les chose. Essayez Multicorn...
En granularité des droits : On a pas encore les privilèges par colonne (mais ça arrive en 9.5), mais sinon les réécritures dynamiques de requêtes ou les tables fonctionnelles permettent de limiter grandement les éléments accédés par un utilisateur. Personnellement je préfère - mais ça demande un peu plus de dev.
En ce qui concerne les framework de développement rapide : MWAHAHAHA ... Désolé, j'ai pas pu m'en empécher.
Le dernier point ou Oracle a encore un gros avantage sur PostgreSQL c'est sur les clusters actifs/actifs pour des bases de données de plusieurs Go (voire To) sur lesquelles aucun partitionnement n'est raisonnablement envisageable. Mais déjà ça se réduit à chaque version, et ensuite dans le pire des cas il suffit souvent de faire appel à Entreprise DB (ou plus rarement à Citus si vraiment les besoins en I/O sont très élevé) pour résoudre le problème avec un cout de licence sans commune mesure avec Oracle.