Rédaction guide choix SGBD

[fgalves]

Bonjour à tous,

J'ai commencé à rédiger il y a quelque temps un guide de choix SGBD; ce guide est destiné à tous les utilisateurs du service BD de notre DSI (il devrait permettre de choisir le SGBD le plus adapté à leur besoins).
Le choix porte sur les produits suivants: Oracle 10gR2, SQL Server 2008, MySQL 5.1 et PostgreSQL 9.

Pour la rédaction de ce document, j'avais listé toutes les caractéristiques basiques et avancées d'un SGBD relationnel (respect de la norme SQL, conformité ACID, support transactionnel, gestion des verrous, intégrité référentielle, contraintes déclaratives, procédures stockées, triggers, UDF, curseurs, types de données, ........). Mon idée initiale (trop ambitieuse) était d'évaluer chaque caractéristique ou fonctionnalité par séparé: pour chaque caractéristique/fonctionnalité, une note (1 à 10) est attribuée à chacun des SGBD pour indiquer la qualité de la solution implémentée pour une telle fonctionnalité. Autrement dit, je voulais aller plus loin que le simple fait de dire si une fonctionnalité est supportée ou non.

Cette approche s'avère trop difficile car il n'est pas évident de comparer les solutions implémentées (il faut être un vrai expert pour connaitre tous les détails de chaque SGBD). En plus, à mon avis les utilisateurs du service BD ne sont pas intéressés en connaître ce niveau de détail mais uniquement de savoir si la fonctionnalité en question est supportée ou non.

Ceci dit, j'aimerais avoir votre avis sur l'approche à suivre pour la rédaction de ce type de document. Peut-être un arbre décisionnel avec des questions qui dirigent vers le SGBD le plus adapté?

Merci d'avance pour votre aide,
Fgalves

[SQLpro]

Faites simple : prenez les 10 fonctionnalités logiques (SQL) + les 10 les fonctionnalités physiques (admin) qui vous paraissent les plus utiles pour votre entreprise et notez OUI / NON.
A partir de là vous pourrez raffiner la chose en élargissant si besoin est à 15, 20...

Un petit mot sur MySQL : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[fgalves]

Merci SQLpro!

Etant donné que tu proposes de noter OUI/NON, pourrais-tu citer quelques exemples de fonctionnalités logiques et physiques pour ces 4 SGBDs qui montrent des différences?
Sauf erreur de ma part, pour les fonctionnalités logiques on devrait avoir des OUI partout... (dans la majorité des cas).

Merci,
Fgalves

[CinePhil]

Envoyé par fgalves

Sauf erreur de ma part, pour les fonctionnalités logiques on devrait avoir des OUI partout... (dans la majorité des cas).

Non !

Sans allez jusqu'aux éléments sophistiqués abordés par SQLPro dans l'article de son blog dont il a donné le lien, MySQL souffre de manques embêtants dès qu'on veut faire un truc un peu sérieux :
- Pas de clés étrangères avec le moteur MyISAM ;
- Pas de contrainte CHECK ;
- Pas de triggers sur les vues ;
- Pas de RAISE ERROR dans les triggers.

Avec ma pratique, certes pas tout à fait basique mais quand même pas non plus experte et hyper sophistiquée et pour des besoins relativement simples, voilà ce qui m'a embêté chez MySQL.

[SQLpro]

Mysl : pas de c=sauvegarde à chaud,
PostGreSQL : pas de solution de haute dispo synchrone
etc...

A +

[Jester]

A noter que dans la pratique on choisit un SGBD aussi (surtout?) avec des critères exogènes au SGBD. Volonté d'être homogène ou volonté des l'équipes qui vont developper dessus, de ses compétences surtout.

Si une équipe a l'habitud ede mysql c'est sans doutes pas une idée de les forcer sur autre chose. Que la base soit meilleure ne va pas changer le fait qu'ils l'utiliseront comme une base MySQL.

J'ai encore vu récemment des problèmes que pouvait résoudre MySQL. Pour de nombreuses utilisations cela fonctionne très bien.

[SQLpro]

Vous oubliez que certains requêtes SQL sont infaisable avec MySQL, pour la bonne et simple raison qu'il fonctionne de manière itérative !

Sans aller jusqu'à l'exemple de Chris Date décrit ici : http://blog.developpez.com/sqlpro/p5...lle-intellige/
Voici une requête qui ne passe pas :

Code :

1
2
3
4
5
6
7
8
9
CREATE TABLE T (C INT UNIQUE);
 
INSERT INTO T VALUES (1);
INSERT INTO T VALUES (2);
INSERT INTO T VALUES (3);
INSERT INTO T VALUES (4);
 
UPDATE T
SET C = C + 1;

Vous obtiendrez systématiquement une error 1062 (duplicate key) parce que travaillant ligne à ligne et non pas de manière ensembliste il plante lors de la transformation de 1 en 2.

Tous les autres SGBDR ne font pas cette erreur.

En cela il viole une règle fondamentale de Codd (père fondateur des SGBDR :
"RÈGLE 7 - Insertion, suppression et modification ensemblistes :
Le SGBDR retourne un ensemble d’éléments en réponse aux requêtes qui lui sont soumises. Il doit pouvoir mettre à jour un ensemble d'éléments en exécutant une seule requête."

A lire : http://sqlpro.developpez.com/SGBDR/ReglesCodd/

Donc on ne peut toujours pas considérer que MySQL est un SGBDR !
C'est un gestionnaire de fichier avec une médiocre sur-couche SQL, mais largement suffisant pour ceux qui veulent faire du Cobol sans Cobol !

A +

[Jester]

Je vais paraître stupide mais je préfèrerais que les autres SGBD aient ce problème (qui ne m'est jamais arrivé et qui est contournable) mais la feature de MySQL permettant de réferencer un alias de la projection dans la clause where ou group by :

Code :

1
2
3
SELECT c+1 AS c2
FROM t
GROUP BY c2

Feature qui n'est que chez MySQL me semble, c'est potentiellement trompeur (il y a des cas de variable masking), mais éviter de recopier un gros 'case when' 2x le vaut vraiment.

Comme quoi l'intérêt d'une feature dépend de l'utilisateur.

[Waldar]

Je ne vois pas en quoi c'est une feature. Le copier / coller existait bien avant MySQL.

Si vraiment le contenu de la colonne est compliqué, on peut aussi le référencer sans surcoût (enfin dans les autres SGBD) dans une vue ou une sous-requête.

Cela signifie surtout que le parseur de requête soit :

1. perd du temps (lire le group by, puis le select, puis le group by)
2. est potentiellement faux (lire le select puis lire le group by)

Je penche pour la seconde solution, ça expliquerait les faux agrégats acceptés par MySQL.

[Jester]

Envoyé par Waldar

Si vraiment le contenu de la colonne est compliqué, on peut aussi le référencer sans surcoût (enfin dans les autres SGBD) dans une vue ou une sous-requête.

La encore ça dépend des priorités, je me fiche que le parseur passe 10 secondes à comprendre ma requête ou que ça double le temps d'exécution. Passer plus de temps à écrire mes requêtes et les rendres moins maintenables (la subquery rajoute une étape sur des requêtes qui en ont souvent 5) m'est beaucoup plus pénalisant.

Dans les cas que je vois, les développeurs font du copier coller. Ca devient complexes, ils cherchent plus à compendre, rajoute des query autour etc ... Puis on m'envoie une requête de 200 lignes avec 40 select (pas de dual) en me disant que plus personne ne la comprend. Cela dit, c'est sur que c'est pas avec MySQL qu'on va faire de telle requêtes.

[SQLpro]

Mais MySQL est une catastrophe en terme de vue car il ne sait pas simplifier les requêtes faites sur les vues....
C'est pourquoi au lieu de modifier l'optimiseur pour qu'il soit au minimum correct, alors on fait du hors norme pour palier les défauts....

A +

[Jester]

Ma dernière phrase était peut être peu claire. Je disais que MySQL ne permet pas de faire de grosse requêtes, tant par son optimiseur que par l'absence du mot clef WITH.

Je viens encore de tomber sur point où MySQL est plus simple, MySQL a la commande CREATE OR REPLACE pour les tables, ce que n'a ni Oracle ni SQL Server (Postgresql l'a). MySQL ne sait pas faire de choses complexes, mais fait simplement (pour le dev) les choses simples. D'où son succès je pense.

[SQLpro]

Jester vous dites encore n'importe quoi : CREATE OR REPLACE existe pour Oracle.
Renseignez vous avant de propager des mensonges pour discréditer certains au profit de MySQL !

Mais cela ne fait effectivement pas partie de la norme SQL

A +

[Oishiiii]

A vrai dire Oracle ne propose pas la propriété OR REPLACE sur la création de table ou la création d'index, mais cela fonctionne pour d'autre objets comme les vues, les fonctions ou les procédures stockées.

De toute façon ce genre de détail sans importance n'est un pas critère pertinent pour le choix d'un SGBDR.

Si réaliser un IF EXISTS() sur SQL Server pour tester l'existence d'une table est trop complexe, ou en tout cas pas assez "simple", autant arrêter l'informatique immédiatement.

[Waldar]

Non effectivement l'option n'existe pas pour les tables chez Oracle, il faut faire un contrôle par du PL/SQL si on souhaite effectuer cette opération.

Mais quel est l'intérêt de cette fonction ?
Une modèle qui bouge hors mise à jour applicatif est un modèle mal conçu.

Le seul cas de figure où j'y cerne un intérêt serait en cours de développement.
Mais dans ce cas il suffit de faire un DROP TABLE avant.

La encore ça dépend des priorités, je me fiche que le parseur passe 10 secondes à comprendre ma requête ou que ça double le temps d'exécution. Passer plus de temps à écrire mes requêtes et les rendres moins maintenables (la subquery rajoute une étape sur des requêtes qui en ont souvent 5) m'est beaucoup plus pénalisant.

Vous êtes dangereux ! Si la maintenabilité du code est certes essentielle, les performances le sont sûrement un peu plus.
Ce sont les commentaires, l'indentation et la bonne utilisation des vues imbriquées / tables dérivées qui rende une requête lisible et maintenable.

[fgalves]

Bonjour à tous,

Même s'il n'est pas discriminant, j'avais pensé en ajouter le critère "respect de la norme SQL". SQL a été normalisé à 6 reprises (SQL87, SQL-89, SQL2, SQL3, SQL:2003, SQL:2008).
D'après ce que j'ai pu comprendre, la norme est cumulative: ce qu'il y a dans la 2008 reprend tout ce qu'il y a avant. Tous les SGBDR du marché tentent - plus ou moins bien - à s'approcher de la norme, mais pour des raisons commerciales, aucun n'est pleinement compatible avec. Chaque éditeur tend à développer son propre dialecte, c'est-à-dire à rajouter des éléments hors de la norme.

Oracle
Oracle est pratiquement conforme aux normes SQL-89, SQL-92 (SQL 2), SQL :1999 (SQL3) et SQL:2003. Oracle supporte aussi la plupart des fonctionnalités majeures de SQL:2008.
Respect de la norme: Bon

SQL Server
SQL Server est pratiquement conforme aux normes SQL-89, SQL-92 (SQL 2), SQL :1999 (SQL3) et SQL:2003. SQL Server supporte aussi la plupart des fonctionnalités majeures de SQL:2008.
Respect de la norme: Bon

PostgreSQL
PostgreSQL est pratiquement conforme (de plus en plus conforme) aux normes SQL-89, SQL-92 (SQL 2), SQL:1999 (SQL3) et SQL:2003. PostgreSQL supporte aussi la plupart des fonctionnalités majeures de SQL:2008.
Respect de la norme: Bon

MySQL
MySQL est conforme à la plupart des fonctionnalités majeures des normes SQL-89, SQL-92 (SQL 2), SQL :1999 (SQL3) et SQL :2003.
Cependant, certaines carences font de MySQL le SGBD le plus éloigné de la norme.
Respect de la norme: Moyen

Êtes-vous d'accord avec cette catégorisation?

Merci!
A+

[Jester]

Envoyé par SQLpro

Jester vous dites encore n'importe quoi : CREATE OR REPLACE existe pour Oracle.
Renseignez vous avant de propager des mensonges pour discréditer certains au profit de MySQL !

Je vous propose de lire avant de critiquer, j'ai mis "la commande CREATE OR REPLACE pour les tables, ce que n'a ni Oracle".

Si la maintenabilité du code est certes essentielle, les performances le sont sûrement un peu plus.

Ma conception est que les temps humains sont plus importants que les temps machines. Mes requêtes sont exécutées au plus une fois par semaine et sont classée en trois groupes, moins de 1 minutes, moins de 12h et plus de 12h (i.e. ça va pas aller là). Alors 5 secondes ...

Pour la maintenance je suis d'accord, mais si ça ne tient plus sur un écran ou une page A4, chaque caractère/ligne en plus réduit la lisibilité.

Pour le drop table je l'utilise pour de tables intermédiaires dans un processus automatique d'alimentation (ETL).

fgalves > Notez que Oracle et Postgresql ont des syntaxes proches. L'un ou l'autre est assez proche pour le developpeur de requêtes. Au niveau de l'aisance d'écriture, je trouve SQL Server en retrait par rapport aux autres, mais c'est subjectif à chacun je pense (Mysql est ok pour de petites requêtes, dernier pour les complexes à cause de l'absence de WITH).

[SQLpro]

Envoyé par fgalves

Bonjour à tous,

Même s'il n'est pas discriminant, j'avais pensé en ajouter le critère "respect de la norme SQL". SQL a été normalisé à 6 reprises (SQL87, SQL-89, SQL2, SQL3, SQL:2003, SQL:2008).
D'après ce que j'ai pu comprendre, la norme est cumulative: ce qu'il y a dans la 2008 reprend tout ce qu'il y a avant. Tous les SGBDR du marché tentent - plus ou moins bien - à s'approcher de la norme, mais pour des raisons commerciales, aucun n'est pleinement compatible avec. Chaque éditeur tend à développer son propre dialecte, c'est-à-dire à rajouter des éléments hors de la norme.

ATTENTION... Vous confondez deux choses, bien distinctes :
1) le niveau de fonctionnalité
2) la conformité à la norme.
Ainsi si l'on peut dire qu'au niveau des fonctionnalités Oracle, SQL Server et IBM DB2 se tiennent dans un mouchoir de poche, il en va tout autrement du respect de la norme SQL.
A vu de nez aujourd'hui (basé sur une étude comparative qu'avait fait un de mes étudiant comme mémoire de fin d'année, il y a quelques années) je dirais que :

• IBM DB2 est le plus conforme avec un taux de plus de 95%
• SQL Server est conforme à plus de 85%
• Oracle est conforme à moins de 50% !!!

Cela peut paraître étonnant, mais Oracle à toujours voulu faire son SQL à lui sans tenir compte de la norme.
Quelques exemples en "pur" SQL :

• CONNECT BY ... PRIOR spécifique à Oracle pour les requêtes récursives.
• TO_CHAR, TO_NUMBER... au lieu de CAST
• DECODE... au lieu de CASE
• NLS pour simuler (très très très mal) les collations....

Quand à MySQL il ne respecte même pas les 3/4 de la norme SQL 2 de 1992 !!!
N'étant même pas ensembliste on ne peut pas le qulifier de SGBDR. Ce n'est même pas digne de certains SGBDR fichier comme DBase ou FoxPro !

A +

[Jester]

Je suis d'accord avec SQLPro sauf que je ne crois plus à la norme.

Oracle sait aussi faire du cast et du case. Le decode et to_char sont justes parfait, ce serait dommage des les enlever. Plutôt un manque de la norme.

MySQL respecte peut être plus la norme que vous pensez en mode strict.

[Waldar]

Oracle n'a pas toujours eu une bonne politique vis-à-vis de la norme dans les années 90 se basant sur l'excuse d'avoir implémenté la plupart des fonctionnalités avant qu'elles ne soient décrites et normées.

Néanmoins depuis dix ans, ils ont rattrapé presque tout le retard.
Ainsi si les fonctions de bases continuent d'exister pour des raisons de compatibilité, leurs équivalents normés fonctionnent parfaitement (CAST, CTE & CTE récursives, CASE, jointures ANSI...).

Je m'inquiète plus du SQL de MS qui n'a que très très peu évolué entre les versions 2005 et 2011, et qui commence aussi à vieillir pour le coup, cf. ce sujet !