Le seul point qui je vois en faveur de PostgreSQL est le prix.
pourrais-tu argumenter ?
Les sujets dont tu parles demandent justement d'y mettre le prix (et les compétences) et cela vaut le coût de regarder du côté de PostgreSQL dans ce cas là (car bon côté Oracle, passé 1 To c'est à la ramasse aussi, s'appuyant sur des baies pour les snapshots - aka BCV en local ou SRDF en distant - sur un slave pour pouvoir l'arrêter pour le copier, digne de MySQL pour ses sauvegardes… une opération de base en exploitation…)
Pour le parallélisme, ah bah Oracle là quadruple le prix avec son Oracle RAC (aka, "tu raques") entre le coût de la licence et des compétences liées à la complexité (limitées par le produit choisi, je n'ai vu RAC mis en œuvre que 3 fois : 2 fois sur des bases petites, 1 fois sur une base conséquente, pour des coûts pas forcément acceptables en temps normal…).
J'ai plutôt vu du MySQL répondant en actif/actif et efficacement (bon avec du slave pour les sauvegardes) pour faire du 24/24, ce qu'aurait fait un bon DBA connaissant PostgreSQL et son exploitation de base, vu qu'il est assez bien outillé par défaut (cela ne demande que de la compétence pour le mettre en œuvre, un peu de temps et d'industrialisation dans le contexte demandé, soit du standard à qui s'investit normalement, sans avoir trop à se battre avec l'éditeur pour y arriver en plus vu que les experts PostgreSQL sont réactifs sur les ML, eux :D).
[^] # Re: [^] [-] # Re: question bête
Posté par BAud (site web personnel) . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 4.
pourrais-tu argumenter ?
Les sujets dont tu parles demandent justement d'y mettre le prix (et les compétences) et cela vaut le coût de regarder du côté de PostgreSQL dans ce cas là (car bon côté Oracle, passé 1 To c'est à la ramasse aussi, s'appuyant sur des baies pour les snapshots - aka BCV en local ou SRDF en distant - sur un slave pour pouvoir l'arrêter pour le copier, digne de MySQL pour ses sauvegardes… une opération de base en exploitation…)
Pour le parallélisme, ah bah Oracle là quadruple le prix avec son Oracle RAC (aka, "tu raques") entre le coût de la licence et des compétences liées à la complexité (limitées par le produit choisi, je n'ai vu RAC mis en œuvre que 3 fois : 2 fois sur des bases petites, 1 fois sur une base conséquente, pour des coûts pas forcément acceptables en temps normal…).
J'ai plutôt vu du MySQL répondant en actif/actif et efficacement (bon avec du slave pour les sauvegardes) pour faire du 24/24, ce qu'aurait fait un bon DBA connaissant PostgreSQL et son exploitation de base, vu qu'il est assez bien outillé par défaut (cela ne demande que de la compétence pour le mettre en œuvre, un peu de temps et d'industrialisation dans le contexte demandé, soit du standard à qui s'investit normalement, sans avoir trop à se battre avec l'éditeur pour y arriver en plus vu que les experts PostgreSQL sont réactifs sur les ML, eux :D).