Discussion :

[Fabien Celaia]

Bonjour,

Vous connaissez sans doute déjà le comparatif des SGBDR.

Cet article a pour but d'aider au choix d'un SGBDR. Il se veut impartial, mais sur un sujet si sensible aux "Guerres de religions", il est difficile de se faire un avis sans être "pollué" par des querelles partisanes.

Je vous propose donc, en enfilade, de relever les points positifs, mais surtout négatifs que vous rencontrer à l'usage de vos divers SGBDR.

Je l'annonce d'entrée de jeu afin de ne pas vous faire perdre de temps et d'éviter du stress à tout le monde, et de la modération intempestive:

1. il y a des débats déjà actifs sur les divers forums. Evitez donc d'en ouvrir un ici. La question ici n'est pas de défendre un produit, mais de relever ses faiblesses et ses richesses.
2. Tous les points relevés seront analysés. Au besoin, le comparatif sera enrichi ou/et corrigé. Le comparatif reste cependant un article ayant un auteur et des contributeurs. Après réflexion, c'est le seul moyen de garder une ligne rédactionnelle dans ce type d'article.
3. Il est plus difficile de relever les points négatifs d'un SGBDR que les points positifs (annoncés haut et forts par les éditeurs). Nous attendons donc de vous des critiques arguments étayés.

D'avance merci de vos contributions


Retrouvez tous les meilleurs cours et tutoriels pour apprendre les SGBD

[SQLpro]

MS SQL Server 2008 :

Avantages :
Niveau de SQL très près de la norme SQL et implémente presque toutes les possibilités de SQL.
IHM très complète facilitant la production
Administration aisée et très complète

Inconvénients :
Mono plateforme (Windows only)
Manques au niveau du langage SQL :

• Pas de contraintes d'unicité multi null
• Pas d'implémentation totale du Row Value Constructor
• Pas de fenêtre avancée dans les fonctions de fenêtrage (Cause SQL Window)

Compétiteur d'Oracle ou IBM DB2

Pour mySQL je dirais que son inconvénient qui me parait le plus grave est son incapacité à effectuer des sauvegardes cohérente à chaud.

A +

[Fabien Celaia]

Merci SQLPro/Fred

Pour les avantages, ils étaient déjà intégrés au comparatif
J'ai ajouté qq inconvénients, mais il faudrait en faire de même pour les autres bases.

Pour Mysql, il semblerait que les sauvegardes à chaud soient maintenant possibles... J'avais ça en inconvénient, mais je l'ai ôté...

J'en profite pour annoncer que j'ai passé la rubrique MySQL et JavaDB sous Oracle, puisque Sun vient de se faire "gober"...

[SQLpro]

ha non, là je suis pas d'accord. Les sauvegardes à chaud MySQL existent mais ne permettent en aucun cas d'assurer l'intégrité de la base... La sauvegarde se faisant table par table sans les transaction on peut donc se retrouver avec un facture sans le client alors qu'il existe bien une contrainte d'IR...

Donc, pour moi c'est pas une vraie sauvegarde à chaud !!!

A +

[Jester]

Je crois que pour MySql, il faudrait mettre entre parenthèse le moteur de stockage dont on parle. InnoDB a bien le backup à chaud (avec les 4 modes de transactions). Il me semble que c'est le seul moteur de mysql qui a cela (le seul qui en ait besoin?).

Alors que la recherche full text, il n'y a que myisam.

Souvent dans les benchs on parle de mysql-myisam et mysql-innodb à part. Cela va empirer dans les prochaines années, il y a déjà plusieurs version de innodb, des moteurs comme infobright qui n'ont rien à voir ...

[orafrance]

je me permets quelques remarques sur Oracle :

Prix exhorbitant, tant au point de vue des licences que des composants matériels (RAM, CPU) à fournir pour de bonnes performances

Il faudrait quand même ajouter qu'il existe une version gratuite et que les instances de test ne requiert pas l'achat de licence

D'ailleurs, tu écris : SQL Server, MSDE et SQL 2008 Express mais pas : Oracle Lite, Standard/Entreprise, Apex et Oracle express

Fort demandeur de ressources, ce qui n'arrange rien au point précité, Oracle est bien plus gourmand en ressource mémoire que ses concurrents, ce qui implique un investissement matériel non négligeable. La connexion utilisateur nécessite par exemple près de 700 Ko/utilisateur, contre une petite centaine sur des serverus MS-SQL ou Sybase ASE.

Note que tu peux configurer la connexion partager (multi-thread server ou MTS ) qui permet d'ouvrir un process pour un pool de connexion.

Gourmand aussi en espace disques puisque la plupart des modules requièrent leur propre ORACLE_HOME de par le versionning de patches incontrôle

Ca j'ai pas compris Chaque outil Oracle a son propre HOME c'est ça ? Mais c'est quelques Mo seulement non ?

Gestion des verrous mortels mal conçue (suppression d'une commande bloquante sans rollback)

Non, si Oracle tue la session alors il y a rollback... ou alors c'est un bug

Nombreuses failles de sécurités liées à l'architecture elle-même

Là t'es vraiment pas assez sévère et ça devrait être un inconvénient visible plus tôt. En effet, Oracle est le pire SGBD en terme de sécurité avec un cryptage de user/password farfelue, des failles datant d'Oracle V7 (update de table possible en ayant uniquement les privilèges CREATE ANY VIEW et SELECT ANY TABLE), manque de réactivité, mise à jour du moteur java qui ne suit la régularité de Sun, etc... C'est vraiment LE point noir d'Oracle selon moi

A propos de la complexité de l'admin, on peut aussi ajouter que si les fonctionnalités sont nombreuses elles sont malheureusement aussi riche que complexe à mettre en oeuvre. Quand le mirroring de SQL Server se fait en 5 minutes, sous Dataguard c'est une vraie galère pour réussir un failover automatique. Streams veut tout faire et est vraiment trop compliqué pour de la répli classique.

Et dans les points positifs, tu devrais parler de la console qui est accompagnée de nombreux assistant et alertes pour réduire très largement les tâches d'admin récurentes. En revanche on peut regretter que AWR soit un module payant.

Dans les points négatif de SQL Server, j'ajouterais que le diagnostic des problèmes de performance n'est pas aisé. C'est pas évident d'avoir les requêtes les plus couteuses/database par exemple. Tout ça à cause de l'outil de perf de Windows qui est d'une ergonomie pour le moins... discutable Et dans les positifs, une très bonne réactivité pour corriger les failles de sécurité et une sécurité du SGBD à la hauteur de la sécurité de leur OS... l'inconvénient mono-plateforme en devient un avantage

C'est tout

[Vincent Rogier]

MS SQL Server 2008 :

Avantages :
Niveau de SQL très près de la norme SQL et implémente presque toutes les possibilités de SQL.

Affirmation non vérifiable (donc subjective) car le souci est qu'il est impossible de trouver quoi que ce soit la dessus. Donc aucun élément de référence objectif.

A moins que SqlPro m'en sorte de son chapeau magique.

D'autres SGBD publient leur conformance à la norme ISO mais SqlServer apparemment non...

On sait que Oracle n'est pas 100% conforme (et de loin) mais au moins eux ils le disent et sont clairs la dessus (description détaillée de leur conformance module par module de la norme)

De plus la norme ne concerne pas que le langage SQL au sens strict du terme, mais aussi par exemple la fourniture de embedded SQL, etc..

sinon concernant le comparatif en lui même, les introductions de Oracle et Sybase me semblent un peu trop subjectives
Celle d'oracle carrément hors propos avec la comparaison avec MySql qui n'a pas de sens car il sont dans des niches différentes... On aurait pu faire la même intro pour Sybase ou BD2 en les comparant en MySql....

Ma foi...

[SuperNiKo]

Hello tous,

Je me permets d'embrayer là dessus pour savoir qui, selon vous, domine le marché ?
Je veux dire, j'ai quelques vagues notions de BDD vu en cours et principalement sur du Oracle à cause d' un enseignant chercheur qui a travillé avec eux. Selon lui c 'est Oracle et le reste du monde.

Est ce vraiment comme ça ? De tête et avec ma toute petite expérience, j'ai l 'impression que c 'est :
- IBM DB2 pour les trés grands comptes (3suisses, la redoute...)
- Mysql pour les joujous sur internet ( à quelques exceptions prêt comme toujours ), trés utilisé mais pour des petites bases.
- Microsoft SQL pour les utilisateurs de .Net
- Oracle tout le reste..

Vrai/ faux ?

[orafrance]

Non, il n'y a pas particulièrement de partage comme ça, tu trouves aussi de très grosses bases sous SQL ou Oracle pour des sites web... et du MySQL pour des outils de gestion... donc bon... on peut pas vraiment classifier de la sorte

[Vincent Rogier]

- IBM DB2 pour les trés grands comptes (3suisses, la redoute...)

Il y a beaucoup plus de "tres grand compte" sous oracle que sous DB2....
Oracle est surtout présent dans le bancaire et l'industriel puis ensuite dans le reste

[al1_24]

Tu as sans doute fait un raccourci entre grands comptes et gros systèmes.
DB2 est très présent sur les gros systèmes, plus utilisés par des grands comptes que par des petites structures

[SQLpro]

Affirmation non vérifiable (donc subjective) car le souci est qu'il est impossible de trouver quoi que ce soit la dessus. Donc aucun élément de référence objectif.

A moins que SqlPro m'en sorte de son chapeau magique.

D'autres SGBD publient leur conformance à la norme ISO mais SqlServer apparemment non...

C'est bien plus simple dans SQL Server puisque c'est automatisé au niveau du moteur. En effet la mise en place du flag SET FIPS_FLAGGER permet de flaguer toutes les commandes et leur niveau de conformité. Vous pouvez donc juger par vous même !

Syntaxe

SET FIPS_FLAGGER 'level'


Arguments
' level '
Niveau de conformité à la norme FIPS 127-2, vérifié dans toutes les opérations effectuées dans les bases de données. Si une opération de base de données entre en conflit avec le niveau des normes ISO choisi, Microsoft SQL Server génère un avertissement.

Le paramètre level doit prendre l'une des valeurs suivantes :

Valeur Description
ENTRY
Vérification des normes pour la conformité ISO de base.

FULL
Vérification des normes pour la conformité ISO complète.

INTERMEDIATE
Vérification des normes pour la conformité ISO de niveau intermédiaire.

OFF
Pas de vérification des normes.


Remarques
L'option SET FIPS_FLAGGER est appliquée lors de l'analyse, et non pas lors de l'exécution. Par conséquent, si l'instruction SET est présente dans la procédure stockée ou le traitement d'instructions, elle devient effective, que l'exécution du code ait réellement atteint ou non ce point ; l'instruction SET devient effective avant l'exécution de toute autre instruction

A +

[Fabien Celaia]

J'ai corrigé (enfin... re-re-re-corrigé) les sauvegardes à chaud sur MySQL en supprimant la remarque Innodb.

J'en profite pour assumer ma remarque, toujours sur MySQL, concernant les vues matérialisées, selon un échange d'email que j'ai eu:

Ce Monsieur réagis au comparatif des SGBD qui spécifie que pour MySQL, les vues matérialisées n'existent pas.

A l'époque (2005), je me suis référé à un commentaire dans un forum : http://mysql.ifrance.com/archive/index.php/t-150.html

En v.5, on en eat toujours à de la simulation : http://dev.mysql.com/doc/refman/5.0/en/create-view.html

Il se peut que dans sa dernière version, MySQL comprenne cette notion de vue matérialisée, mais je ne l'ai pas encore trouvée... donc pas encore modifié le désavantage du comparatif.

Ils en parlent souvent, mais simulent en fait la MV avec une table de travail qu'ils rafraichissent par purge... ce qui n'est pas de la MV à proprement parler...

En cas de preuve du contraire, je corrigerai

m.s.
Fadace

Bonjour Fadace,

Ci dessous un msg reçu d'un internaute, je ne vois pas trop de quelle page il parle . Peux-tu voir et me dire si çà retombe chez moi ?



--------- Message transféré ----------
De : <pxxxxxxxxxxxxx@viamichelin.com>
Date : 30 juin 2009 17:59
Objet : Dans l'article Quel SGBD choisir ...
À : sgbd@redaction-developpez.com



Bonjour,

Dans la partie MySQL, il semble que les vues soient présentes contrairement à ce qu'il est indiqué.

Cordialement,

Paul

[ced]

Bonjour,

Dans le comparatif, il est mis, dans les inconvénients de MySQL (toujours lui ) que seul le moteur Falcon gère les transactions.
Pourtant, InnoDB le fait également...
C'est le moteur MyISAM qui ne gérait pas les transactions...

De même, il est écrit qu'il n'y a pas d'ordonnanceur intégré. Eh bien c'est également à nuancer, parce qu'il existe un ordonnanceur dans la version 5.1 (la dernière version de production de MySQL).

Egalement, il est écrit qu'il n'y a pas de partitionnement. Pourtant, c'est bien le cas en version 5.1...

ced

Corrigé dans le comparatif / Fadace