Discussion :

[bnoir]

quelle erst la difference majeure entre oracle et mysql
quels sont les avantages d'oracle par rapport à mysql ??

[Marc Lussac]

Tu à lu le comparatif SGBD ?

[SQLpro]

Oracle exploite des bases de données relationnelles depuis plus de 20 ans et certaines bases dépassent les 120 Téra octets.
MySQL exploite des bases de données RELATIONNELLES depuis moins de 2 ans et peu de bases exploitées de manière RELATIONNELLES dépassent quelque giga octets...

A +

[Invité]

MySQL est à Oracle ce que DACIA est à Renault....

[Antoun]

Oracle est sans doute plus puissant, plus éprouvé, etc. Néanmoins, son dialecte SQL, qui a été à la pointe autrefois, est assez éloigné de la norme SQL (cela s'améliore) et surtout très pauvre. Ainsi, Oracle 10 ne permet pas le regroupement externe (j'ai même un doute sur le tri externe), ne connait pas la clause LIMIT, a une implémentation réduite du constructeur de ligne (alors qu'il a été l'un des premiers à mettre en place cette syntaxe).

Les versions 4.1 et 5 de MySQL apportent tout cela, ainsi que des innovations particulièrement intéressantes, notamment une optimisation des regroupements (qui permet d'écrire par exemple un requête comme SELECT Nom, Prenom ... GROUP BY IDpersonne) et la fonction d'agrégation par concaténation GROUP_CONCAT().

En gros, disons qu'Oracle est une grosse usine super puissante mais pas très innovante, tandis que la dernière version de MySQL est un petit labo de recherche, avec un côté un peu bricolo mais plein d'idées passionantes !


--
Antoun

Guide complet MySQL 5, par Antoine Dinimant, éd. MicroApplication
http://www.microapp.com/livre_mysql_7873.html

[SQLpro]

Antoun raconte :

Oracle est sans doute plus puissant, plus éprouvé, etc. Néanmoins, son dialecte SQL, qui a été à la pointe autrefois, est assez éloigné de la norme SQL (cela s'améliore) et surtout très pauvre. Ainsi, Oracle 10 ne permet pas le regroupement externe (j'ai même un doute sur le tri externe), ne connait pas la clause LIMIT, a une implémentation réduite du constructeur de ligne (alors qu'il a été l'un des premiers à mettre en place cette syntaxe).

clause LIMIT : cela n'existe pas en SQL (norme) en revanche il existe des outils purement SQL (à la norme) bie plus puissants pour ce faire : les fonction de fenêtrage. Oracle en implémente la plupart. Pas MySQL !

une implémentation réduite du constructeur de ligne : aucun SGBDR n'a une implémentation complète du ROW VALUE CONSTRUCTOR.

Antoun raconte aussi :

Les versions 4.1 et 5 de MySQL apportent tout cela, ainsi que des innovations particulièrement intéressantes, notamment une optimisation des regroupements (qui permet d'écrire par exemple un requête comme SELECT Nom, Prenom ... GROUP BY IDpersonne) et la fonction d'agrégation par concaténation GROUP_CONCAT().

GROUP_CONCAT() : n'existe pas en SQL. En revanche pour des agrégats cumulatifs la norme SQL prévoit GROUP BY CUBE, GROUP BY ROLLUP, qui existe je crois sous Oracle.

CONCLUSION : vous démolissez Oracle en croyant faussement que ce que fait MySQL est meilleur. Mais MySQL est très loin d'implémenter toutes les finesses du langage SQL et de plus il est très anti normatif !

Oracle permet bien évidemment de faire beaucoup plus de choses, même s'il est effectivement en retard sur la norme SQL.

A +

[CiTriX]

Pour la moi la différence majeure c'est le prix ...

[Antoun]

Ah, un peu de bonne polémique instructive !

clause LIMIT : cela n'existe pas en SQL (norme) en revanche il existe des outils purement SQL (à la norme) bie plus puissants pour ce faire : les fonction de fenêtrage. Oracle en implémente la plupart. Pas MySQL !

LIMIT n'est pas normée c'est exact ; elle correspond néanmoins au TOP de SQL Server et SyBase (sans les options PERCENT et WITH TIES). A ma connaissance, Oracle n'avait pas de mécanisme équivalent (à part placer des conditions sur le ROWNUM, mais cela force à faire une sous-requête).

Si tu me dis que les fonctions de fenêtrage, qu'effectivement je ne connaissais pas, permettent d'implémenter cela, je retire mon objection et je te remercie pour la leçon !

une implémentation réduite du constructeur de ligne : aucun SGBDR n'a une implémentation complète du ROW VALUE CONSTRUCTOR.

J'ai bossé sur un Oracle 10g en juillet, et pas mal galéré pour faire des requêtes qui auraient été simples avec MySQL ou SQL Server. Parmi les tests, j'ai constaté, entre autres, que (col1, col2) < (constante1, constante2) marchait, mais que (col1, col2) < (col3, col4) ne fonctionnait pas (ou en tout cas pas dans les conditions de mon test - mais je te fais confiance pour infirmer mon diagnostic si ce n'est pas le cas ). MySQL 5 permet ce genre d'écriture sans problème.

GROUP_CONCAT() : n'existe pas en SQL.

c'est exactement la raison pour laquelle je la présente comme une innovation de MySQL. Ta remarque est de mauvaise foi, ou alors tu es aveuglé par la mysqlophobie.

Comme tu ne sembles avoir aucune idée de ce qu'est une agrégation par concaténation (ou ne pas vouloir le savoir), permets-moi de te renvoyer à l'exemple 2 de ton article "éviter les curseurs sous MS SQL Server" http://sqlpro.developpez.com/cours/s...voidCursor/#L2.

Avec MySQL, il y aurait une solution bcp plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
SELECT GROUP_CONCAT(
  JOR_PRENOM 
  ORDER BY  JOR_PRENOM
  SEPARATOR ', '
)
FROM   T_JOUEUR_JOR ;

Comme c'est une fonction d'agrégation comparable à SUM(), COUNT(), etc., on pourrait aller plus loin et faire par exemple la liste alphabétique des joueurs de chaque équipe en rajoutant juste une clause GROUP BY sur l'équipe.

Comme tu t'es toi-même penché sur le problème de l'agrégation par concaténation, je pense que tu reconnaîtras sans problème l'utilité et la simplicité de GROUP_CONCAT(), et que tu souhaiteras comme moi qu'elle soit intégrée à la prochaine normalisation de SQL.

En revanche pour des agrégats cumulatifs la norme SQL prévoit GROUP BY CUBE, GROUP BY ROLLUP, qui existe je crois sous Oracle.

Tout ceci n'a pas grand-chose à voir avec la choucroute, mais j'en profite pour signaler que MySQL 5 implémente le ROLLUP mais pas le CUBE.

CONCLUSION : vous démolissez Oracle en croyant faussement que ce que fait MySQL est meilleur. Mais MySQL est très loin d'implémenter toutes les finesses du langage SQL et de plus il est très anti normatif !

Oracle permet bien évidemment de faire beaucoup plus de choses, même s'il est effectivement en retard sur la norme SQL.

Je ne crois pas démolir Oracle. Je reconnais ses qualités tout en pointant ses retards (que tu reconnais toi-même), qui sont bcp moins connus, d'où le fait que je mette l'accent là-dessus.

Quant à MySQL, il est loin d'être parfait et je ne le prétend pas. Mais les versions 4.1 et 5 représentent un saut générationnel important. Ce SGBD propose maintenant la plupart des "finesses" du SQL, qui lui manquaient effectivement avant : contraintes d'intégrité référentielle, sous-requêtes, vues, procédures et fonctions stockées, triggers, collations, prepared statements, etc. Cela se fait parfois de manière un peu artisanale (par exemple, les vues ne sont pas compilées), mais en tout cas, il serait faux de dire qu'Oracle est meilleur à tous les points de vue.

Enfin, le dialecte de MySQL se rapproche de plus en plus de la norme ; au total il me semble sans doute moins éloigné que celui d'Oracle.

--
Antoun

Guide complet MySQL 5, par Antoine Dinimant, éd. MicroApplication
http://www.microapp.com/livre_mysql_7873.html

[Erwy]

Je vais uniquement prêché pour ma paroisse ici, mais les fonctionnalités xml intégré à ORACLE
comme la possiblité d'obtenir directement un format XML
- soit canonique, avec une procédure stocké très simple
- soit plus complexe avec XSQL (il y en à d'autre mais que je trouve moins pratique)
ou celle de valider un XML entrant (sortant aussi mais normallement l'intérêt est moindre)
sont des options qui dans mon cas me simplifie la vie
(On peut aussi effectuer des transformation mais la je trouve le proc oracle encore un peu faiblart et peu interessant).
Ce n'est peut être pas la pointe dans ce domaine , mais allié au reste cela en fait un ensemble très inintéressant

[orafrance]

Les versions 4.1 et 5 de MySQL apportent tout cela, ainsi que des innovations particulièrement intéressantes, notamment une optimisation des regroupements (qui permet d'écrire par exemple un requête comme SELECT Nom, Prenom ... GROUP BY IDpersonne) et la fonction d'agrégation par concaténation GROUP_CONCAT().

Ne parlerais-tu pas des fonctions analytiques ? http://lalystar.developpez.com/fonctionsAnalytiques/

[orafrance]

Comme c'est une fonction d'agrégation comparable à SUM(), COUNT(), etc., on pourrait aller plus loin et faire par exemple la liste alphabétique des joueurs de chaque équipe en rajoutant juste une clause GROUP BY sur l'équipe.

La clause WITH d'Oracle devrait pouvoir répondre à cette problèmatique non ?

Sinon, à mon avis vous n'arrivez pas à vous mettre d'accord parce que vous comparer le SGBD et le langage. A mon avis, si le SQL implémenté par MySQL apporte des aides intéressantes par rapport à Oracle, en revanche, son moteur n'est pas du tout à la hauteur de celui d'Oracle ni même des autres concurrents. On peut espérer que l'acquisition de InnoDB par Oracle permettra d'apporter des avantages comparables à MySQL

[Antoun]

La clause WITH d'Oracle devrait pouvoir répondre à cette problèmatique non ?

à l'exemple SQL Server ???

Sinon, à mon avis vous n'arrivez pas à vous mettre d'accord parce que vous comparer le SGBD et le langage. A mon avis, si le SQL implémenté par MySQL apporte des aides intéressantes par rapport à Oracle, en revanche, son moteur n'est pas du tout à la hauteur de celui d'Oracle ni même des autres concurrents.

Nous sommes donc d'accord

[Antoun]

Ne parlerais-tu pas des fonctions analytiques ?

Non. Sauf gros caca dans l'oeil, je ne vois parmi les fonctions analytiques que cite Laly, comme parmi la liste complète de la doc Oracle, que des fonctions statistiques. GROUP_CONCAT() concatène des textes.

--
Antoun

Guide complet MySQL 5, par Antoine Dinimant, éd. MicroApplication
http://www.microapp.com/livre_mysql_7873.html

[orafrance]

et group by col1||col2 ???

[SQLpro]

Au sujet du GROUP_CONCAT, dont je viens de saisir la chose; il s'agit donc d'une concaténation de chaines de caractères. Ceci est possible par une requête à la norme SQL:1999 en utilisant la technique des CTE (common Table Expression). En particulier DB2 et SQL Server 2005 implémente cela. Donc encore une fois un truc spécifique MySQL inutile et dangereux.

Pour une présentation complèete des CTE et de leurs possibilités :
http://www.sqlservercentral.com/colu...server2005.asp
un article de votre serviteur, traduit dans SQL Server magazine et qui devrait bientôt être posté dans SQLpro.developpez.com !

A +

[Xo]

Pour la moi la différence majeure c'est le prix ...

Oracle est gratuit et pas MySQL ?

[Antoun]

et group by col1||col2 ???

col1||col2 est la concaténation de deux colonnes ; GROUP_CONCAT() est une agrégation (une fonction de GROUP BY), càd qu'elle concatène les valeurs des différentes lignes d'une même colonne.

Dit autrement, GROUP_CONCAT() est à || ce que SUM() est à +.

[Antoun]

Au sujet du GROUP_CONCAT, dont je viens de saisir la chose; il s'agit donc d'une concaténation de chaines de caractères. Ceci est possible par une requête à la norme SQL:1999 en utilisant la technique des CTE (common Table Expression). En particulier DB2 et SQL Server 2005 implémente cela. Donc encore une fois un truc spécifique MySQL inutile et dangereux.

Il reste que GROUP_CONCAT() est bcp + simple que les CTE et parfaitement intégrée au système standard agrégation/regroupement. Mais là, je crains que nous n'en arrivions aux questions de goût !

--
Antoun

Guide complet MySQL 5, par Antoine Dinimant, éd. MicroApplication
http://www.microapp.com/livre_mysql_7873.html

[orafrance]

col1||col2 est la concaténation de deux colonnes ; GROUP_CONCAT() est une agrégation (une fonction de GROUP BY), càd qu'elle concatène les valeurs des différentes lignes d'une même colonne.

Dit autrement, GROUP_CONCAT() est à || ce que SUM() est à +.

A oui OK... en effet, sous Oracle ça peut être pénible mais un PL/SQL régle vite le souci

[Xo]

Il reste que GROUP_CONCAT() est bcp + simple que les CTE et parfaitement intégrée au système standard agrégation/regroupement. Mais là, je crains que nous n'en arrivions aux questions de goût !

Je reconnais pour ma part que cette fonction permet de répondre à un problème fréquemment posé sur le forum SQL, et dont la solution (cf cette proposition : #29) impose que le SGBD concerné réponde à la norme SQL 3, ou bien que l'utilisateur se tourne vers le langage procédural. Reste dans tous les cas le problèmes des performances ...