J'utilise Oracle à titre professionnel depuis plus de 10 ans. Je reconnais que c'est béton. Pas un problème en 10 ans.
Toutefois, j'ai quelques reproches à faire à ce SGBD : il a été conçu à une époque où les systèmes de fichiers étaient encore très sommaires. Rien à voir avec Reiserfs !
En effet, il est nécessaire de réserver la taille des fichiers et la taille de leurs extensions. Quand il y a trop "d'extends", les performances diminuent et l'administrateur du SGBD doit intervenir pour recréer la base de données avec de nouveaux espaces. Un travail lourd mais complètement anachronique. Comme les DSI ont bien souvent de 5 à 10 ans de retard sur notre époque, ils croient que c'est un travail normal et obligatoire.
Avec un file system moderne, ces opérations souvent très lourdes sont prises en compte par le FS. La charge de travail induite par Oracle est un véritable anachronisme.
Un autre reproche : pour exporter les données d'Oracle, il faut acheter des licences complémentaires ou écrire du code. Rien de tout ça avec Postgresql qui possède avec "pg_dump" et "copy" des utilitaires remarquables. L'un est lent mais universel, l'autre est plus spartiate mais très rapide. Actuellement, si je devais recréer une nouvelle (et énorme) application, j'utiliserais Postgresql plutôt qu'Oracle, et ce n'est pas pour le prix des licences!
[^] # Re: Oracle : solide mais archaïque
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à 7.
Toutefois, j'ai quelques reproches à faire à ce SGBD : il a été conçu à une époque où les systèmes de fichiers étaient encore très sommaires. Rien à voir avec Reiserfs !
En effet, il est nécessaire de réserver la taille des fichiers et la taille de leurs extensions. Quand il y a trop "d'extends", les performances diminuent et l'administrateur du SGBD doit intervenir pour recréer la base de données avec de nouveaux espaces. Un travail lourd mais complètement anachronique. Comme les DSI ont bien souvent de 5 à 10 ans de retard sur notre époque, ils croient que c'est un travail normal et obligatoire.
Avec un file system moderne, ces opérations souvent très lourdes sont prises en compte par le FS. La charge de travail induite par Oracle est un véritable anachronisme.
Un autre reproche : pour exporter les données d'Oracle, il faut acheter des licences complémentaires ou écrire du code. Rien de tout ça avec Postgresql qui possède avec "pg_dump" et "copy" des utilitaires remarquables. L'un est lent mais universel, l'autre est plus spartiate mais très rapide. Actuellement, si je devais recréer une nouvelle (et énorme) application, j'utiliserais Postgresql plutôt qu'Oracle, et ce n'est pas pour le prix des licences!