Arguments pour déterminer choix du serveur et du SGBD

[haki75]

Bonjour et meilleurs voeux pour le nouvel an,

Etant plus axé sur le dev que sur l'admin, je choisis le type de serveur et le SGBD que j'utilise à la louche( en fait pour le SGBD je choisi toujours ORACLE car c'est ce que je maitrise le mieux) .

Mais là, je dois convaincre mes supérieurs sur le choix du matériel et du SGBD.

Et le problème est que je suis incapable :
-de défendre le choix du SGBD (à part que j'ai l'habitude de bosser dessus)
-de savoir quel genre de serveur il me faudrait. Je vois bien la puissance des processeurs ou la ram mais il m'est impossible d'en déterminer s'il vont correspondre à ma solution.

Existe t il une espèce de règle du genre "il me faut tel serveur avec tel équipement pour assurer tel solution" ?

Si des connaisseurs pouvaient me donner leurs astuces pour réaliser cela, cela m'aiderait beaucoup

merci !

[CinePhil]

Tu trouveras des éléments de réponse dans ce forum car la question est assez récurrente.
D'autres éléments au début d'un article de SQLPro sur l'optimisation des SGBD. L'article est un peu ancien, il faut actualiser les caractéristiques citées au matériel actuellement présent sur le marché.

Oracle est un bon choix pour une application professionnelle mais c'est onéreux et peut faire prendre quelques mauvaises habitudes avec des éléments de son langage qui lui sont spécifiques.

Autres SGBD sérieux pour une appli professionnelle, critique, avec une grosse BDD : IBM DB2, Microsoft SQL Server

Si l'appli est plus légère, moins critique, si le volume de données est relativement réduit, si le prix est un critère important du choix, tourne toi vers Postgresql qui est probablement le meilleur SGBD open source.

Côté serveur, il faut privilégier une grosse mémoire vive pour que le SGBD travaille au maximum en mémoire et au minimum avec les disques. Si tu peux avoir un serveur dédié au SGBD, c'est encore mieux. Voir l'article de SQLPro pour les détails.

[skuatamad]

Pour moi un des principaux atouts d'oracle est le READ CONSISTENCY, mais SqlServer 2008 a également implémenté une vision snapshot qui aide un développeur oracle à se sentir un peu plus "à la maison".

Sinon oracle c'est de très nombreuses fonctionnalités pour les devs notamment avec un sql très riche pas toujours très normatif certes. Et il est multi plateforme.

Ce sera peut être plus difficile à défendre auprès de tes responsables, mais ton expérience et tes compétence sont un élément important.
En effet un développeur expérimenté sur une base A et travaillant sur une base B sera forcément moins productif et fournira donc soit dans le même laps de temps un code de moins bonne qualité (performance scalabilité) soit un code de qualité équivalente en y consacrant beaucoup plus de temps.
Mais bon c'est vrai que les SSII ont tendance à considérer 3 mois d'expérience comme de l'expertise...

Concerant le coût, oui oracle est généralement plus cher, mais il a quand même une gamme de produit débutant à la version XE(gratuite) en passant par SE1, SE puis EE, après comprendre la facturation des licenses est tellement compliqué que c'en est un métier...
Mais c'est vrai que ces derniers temps la mode consiste plus à payer pour une entreprise edition (quelque soit l'éditeur) pour au final s'en servir uniquement en CRUD.

Il y a une discussion sur asktom, que tu as peut être déjà lu, qui compare oracle aux autres.
Donc évidemment comme elle a débuté en 2001 les choses ont bien évolué notamment pour les concurents mais comme elle se poursuit de façon plus ou moins détaillée jusqu'en 2010 ça peut quand même t'intéresser.

Après concernant le choix du serveur franchement je pense que c'est le boulot d'un admin et pas d'un dev, j'espère qu'un admin passera sur ton post.

Voilà, c'était une petite contribution pro oracle mais comme tu es également plus habitué à oracle, l'idée était de te donner quelques éléments pour défendre ta position.
J'espère que ça pourra t'aider ou à défaut t'intéresser.

[SQLpro]

Aujourd'hui, Oracle SQL Server et DB2 possèdent a peu près les mêmes fonctionnalité dans tous les domaines (richesse du SQL, administration, architecture technique...)
Les différences sont de deux ordres :

1) performances : Oracle reste plus performant que SQL Server au niveau des transactions. Mais SQL Server est plus performant au niveau des lectures...

2) administration : là ya pas photo. Quand on voir l'extrême complexité des sauvegardes d'Oracle (qui a du racheter un outil tiers rman) par rapport à celles de SQL Server... Bref, l'admin est incommensurablement plus simples et plus rapide, générant moins de coût d'exploitation.

3) cout des licences. Là aussi SQL Server est BEAUCOUP BEAUCOUP moins cher entre 2 et 24 fois !!!!
Par exemple Oracle fait payer toutes les licences, même celle des serveurs froids (redondance en haute dispo) alors que chez MS SQL est gratuit tout comme Windows dans ce cas.
En sus Oracle fait payer un licence pour chaque module additionnel :
OLAP, Spatial, Indexation Textuelle... sont des outils payants en sus chez Oracle, alors qu'ils sont intégrés dans presque toutes les versions (sauf OLAP pour la version gratuite SQL Server Express).
Même le mode de paiement des licences est plus avantageux chez MS, car MS ne fait payer que les sockets des CPU. Bref, si vous avez un bipro exacore, vous ne payez au plus que 2 licences processeurs pour bénéficier de 12 coeurs ! Idem en cas de virtualisation. Vous ne payez qu'une seule instance/CPU même si vous installez 16 machines avec 16 instances de SQL Server!!!!!!!

A +

[Waldar]

Si Oracle a racheté RMAN, c'était il y a très très longtemps alors, car il est - d'après cet article - fourni en standard depuis la v8 qui a presque quinze ans !

[TryExceptEnd]

Envoyé par SQLpro

1) performances : Oracle reste plus performant que SQL Server au niveau des transactions. Mais SQL Server est plus performant au niveau des lectures...

Je ne suis pas expert des SGBD, mais je croyait que les lectures se font aussi par des transactions ? c'est pas le serpent qui se mord la queue la ?
Une explication s'impose Mr. SQLpro.

[SQLpro]

Bien que les lectures doivent être considérées comme des transactions à part entière, elles ne sont pas journalisées contrairement aux mises à jour pour lesquelles le journal inscrit les valeurs avant et après la mise à jour de toutes les données modifiées.

A +

[skuatamad]

Envoyé par SQLpro

OLAP, Spatial, Indexation Textuelle... sont des outils payants en sus chez Oracle

Oracle Text est inclu dans toutes les éditions.