C'est bien ce que je lui reproche ! Ce n'est pas son boulot. Le SGBD n'a pas plus à jouer le rôle d'OS que de FS. En plus de ça, ce n'est pas sain : c'est une façon de "fidéliser" les clients-prisonniers.
Gérer les extends est un archaïsme ! Gérer à la main la taille des fichiers non extensibles d'une base de données me parait complètement anachronique. C'est le rôle du FS.
Pour ceux qui ne connaissent pas : On déclare par exemple que le data set "Machin" logera dans 10 Mo et que si il est plein, on lui allouera des extensions de 5 Mo. Lorsque le nombre d'extends augmente, le temps de réponse devient mauvais. Il faut alors décharger et recharger la base de données (ou le data-set si les contraintes d'intégrité le permettent) pour dire que la taille du fichier de base sera de 30Mo avec des extensions de 20Mo.
Oracle, à cause de ses archaïsmes, necessite un administrateur et un système de surveillance assez délicat. Oracle qui a pensé à tout fournit un système de surveillance (payant en supplément) pour cela.
Postgres n'a pas besoin de tout ça. Il suffit de surveiller la place libre sur les disques et c'est tout !
Autre inconvénient : Pour extraire les données d'Oracle et les importer sur un autre SGBD, il faut acheter un logiciel de plus. Alors que dump et copy de postgresql font ça tout naturellement !
NB : Je ne connais pas très bien MySQL. Je crois que c'est pareil. Quelqu'un pour confirmer ?
Oracle a toutefois un avantage sur les autres SGBD : il permet de répartir sa base de données (éventuellement le me data-set) sur plusieurs machines. C'est effectivement bien pratique pour la facturation détaillée de France-Telecom, mais cela ressemble de plus en plus à un marché de niche.
[^] # Re: "Oracle goes linux"
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche Long article sur Linux dans Oracle Magazine. Évalué à 1.
C'est bien ce que je lui reproche ! Ce n'est pas son boulot. Le SGBD n'a pas plus à jouer le rôle d'OS que de FS. En plus de ça, ce n'est pas sain : c'est une façon de "fidéliser" les clients-prisonniers.
Gérer les extends est un archaïsme ! Gérer à la main la taille des fichiers non extensibles d'une base de données me parait complètement anachronique. C'est le rôle du FS.
Pour ceux qui ne connaissent pas : On déclare par exemple que le data set "Machin" logera dans 10 Mo et que si il est plein, on lui allouera des extensions de 5 Mo. Lorsque le nombre d'extends augmente, le temps de réponse devient mauvais. Il faut alors décharger et recharger la base de données (ou le data-set si les contraintes d'intégrité le permettent) pour dire que la taille du fichier de base sera de 30Mo avec des extensions de 20Mo.
Oracle, à cause de ses archaïsmes, necessite un administrateur et un système de surveillance assez délicat. Oracle qui a pensé à tout fournit un système de surveillance (payant en supplément) pour cela.
Postgres n'a pas besoin de tout ça. Il suffit de surveiller la place libre sur les disques et c'est tout !
Autre inconvénient : Pour extraire les données d'Oracle et les importer sur un autre SGBD, il faut acheter un logiciel de plus. Alors que dump et copy de postgresql font ça tout naturellement !
NB : Je ne connais pas très bien MySQL. Je crois que c'est pareil. Quelqu'un pour confirmer ?
Oracle a toutefois un avantage sur les autres SGBD : il permet de répartir sa base de données (éventuellement le me data-set) sur plusieurs machines. C'est effectivement bien pratique pour la facturation détaillée de France-Telecom, mais cela ressemble de plus en plus à un marché de niche.