Discussion :

[ohan]

D�bat

Quelles sont les diff�rences entre MySQL et postgreSQL ?

Que choisir entre Mysql et Postgresql ?

Vos exp�riences avec ces base de donn�es ?



_________________________________________________________
Notes de la mod�ration

Avant de participer au d�bat, merci de commencer par lire le d�bat

Merci de nous faire partager vos exp�riences r�elles

Si vous n'avez pas d'exp�rience sur MySQL ou postGreSQL, merci de ne pas participer au d�bat pour reproduire des propos faux recueillis sur des forums amateurs, ou des propos obsol�tes sur des anciennes versions.

Les propos d�nigrants ou diffamatoires sur ces deux SGBD (post�s g�n�ralement par des amateurs inexp�riment�s) seront supprim�s � vue. Ces deux produits quoi que diff�rents sont tous les deux des produits de qualit�s utilis�s par des professionnels sur des sites de tr�s grande envergure.

[bouchon]

A noter que PostgreSQL est tr�s comparable � MySQL en mati�re de rapidit� de SELECT, et ce depuis la version 7.1.

PostgreSQL devient de plus en plus utilis�...

Certaines grosses pointures utilisent PostgreSQL, comme le site SourceForge par exemple !

Cordialement,

[vanquish]

En r�ponses aux personnes qui �crivent que MySQL ne sait pas g�rer les transactions :

Je cr�e 2 tables identique dans lesquelle j'ins�re 2 lignes dans Chaque

J'�crit en majuscule, non pas pour crier, mais pour distinguer le code SQL des remarques.
J'ai virer les r�ponses de MySQL du type 'Query OK - x line affected'
pour plus de concision.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
CREATION DES TABLES
----------------------------
mysql> create table table1 ( id integer not null , libelle varchar(50) , primary key( id) ) Type = InnoDB ;
 
mysql> create table table2 ( id integer not null , libelle varchar(50) , primary key( id) ) Type = InnoDB ;
 
PASSAGE EN MODE TRANSACTION
----------------------------------------
mysql> set autocommit=0 ;
Query OK, 0 rows affected (0.93 sec)
 
POPULATION DES TABLES 2 RECORD
-------------------------------------------
mysql> insert into table1 VALUES (1 , 'Bonjour' );
mysql> insert into table1 VALUES (2 , 'Salut' );
mysql> insert into table2 VALUES (1 , 'Goodmorning' );
mysql> insert into table2 VALUES (2 , 'hello' );
mysql> commit ;
 
 
UN SELECT POUR VERIFIER L'ETAT DES TABLES
-------------------------------------------------------
 
mysql> select * from table1 ;
+----+---------+
| id | libelle |
+----+---------+
|  1 | Bonjour |
|  2 | Salut   |
+----+---------+
2 rows in set (0.05 sec)
 
mysql> select * from table2 ;
+----+-------------+
| id | libelle     |
+----+-------------+
|  1 | Goodmorning |
|  2 | hello       |
+----+-------------+
2 rows in set (0.01 sec)
 
MAINTENANT J'INSERE DES RECORD QUE JE VAIS ROLLBACKer
--------------------------------------------------------------------------
 
mysql> insert into table1 VALUES (3 , 'Au revoir' );
Query OK, 1 row affected (0.01 sec)
 
mysql> insert into table2 VALUES (3 , 'GoodBye' );
Query OK, 1 row affected (0.01 sec)
 
JE VERIFIE QUE LES RECORD SONT DISPO AU SEIN DE LA TRANSACTION
-------------------------------------------------------------------------------------
 
mysql> select * from table1 ;
+----+-----------+
| id | libelle   |
+----+-----------+
|  1 | Bonjour   |
|  2 | Salut     |
|  3 | Au revoir |
+----+-----------+
3 rows in set (0.00 sec)
 
mysql> select * from table2 ;
+----+-------------+
| id | libelle     |
+----+-------------+
|  1 | Goodmorning |
|  2 | hello       |
|  3 | GoodBye     |
+----+-------------+
3 rows in set (0.00 sec)
 
 
OK - TOUT EST LA ; 3 RECORD/TABLE - MAINTENANT UN UNDO
--------------------------------------------------------------------------
 
mysql> ROLLBACK ;
Query OK, 0 rows affected (0.01 sec)
 
PUIS LES MEME SELECT
---------------------------
 
mysql> select * from table1 ;
+----+---------+
| id | libelle |
+----+---------+
|  1 | Bonjour |
|  2 | Salut   |
+----+---------+
2 rows in set (0.12 sec)
 
mysql> select * from table2 ;
+----+-------------+
| id | libelle     |
+----+-------------+
|  1 | Goodmorning |
|  2 | hello       |
+----+-------------+
2 rows in set (0.02 sec)
 
LE ROLLBACK A BIEN FONCTIONNE - PLUS QUE 2 RECORD
--------------------------------------------------------------------

Donc, en quoi cela n'est-t-il pas de VRAI transaction ou des transaction au niveau table ?

Les modes READ UNCOMMITTED , READ COMMITTED , REPEATABLE READ et SERIALIZABLE sont d�clar� disponible dans la doc (mais honn�tement, je n'ai pas essay� tous les modes).

MySQL int�gre en option depuis la version 3.23.34, le module InnoDB lequel permet transaction (avec multiversioning ) ET int�grit� r�f�rentielle.

Depuis plusieurs version d�j� (au moins la 3.23.50), InnoDB est int�gr� en standard dans le serveur mysqld (plus besoin de mysql-max), l'option �tant devenu son absence.

Il ne s'agit donc pas d'une future hypth�tique version, mais bien de la version en production.

InnodDB poss�de aussi des journaux et un syst�me de double-�criture qui lui permettent une reprise sur crash quasi instantan�e.
L'ACIDit� n'est effectivement que partielle puisque les tables g�rant les droits ne peuvent �tre stock�es au sein d'InnoDB. Mais g�n�ralement ces tables ne bougent pas beaucoup, et on peut donc les sauvegarder une fois pour toute. Au cas o� elle serait cass�es, il suffira alors d'�craser le dossier concern� par sa sauvegarde pour relancer le serveur.

Enfin pour ce qui est des benchs :

http://www.eweek.com/article2/0,3959,293,00.asp

o� mySQL est mis sur un pied d'�galit� avec Oracle9i (en terme de perf s'entend - je n'ai pas dis que les produits �taient comparables).


J'ai travaill� dans la billetterie, et sur 150 salles de spectacles qui avaient entre 250 et 1500 places vendus par soir. A l'�poque on n'avait, ni trigger, ni int�grit� ref�rencielle, ni transaction.
Pourtant , on a jamais vendu deux fois le m�me si�ge et les clients �taient content - n'�tait-ce pas l'essentiel ?

Enfin, la disponibilit� native de MySQL sous Windows est quand m�me un plus quand on n'administre pas soit m�me les serveurs - mais pour un site web, je pense que Ohan aura le choix de son OS.

[UbiK]

Enfin pour ce qui est des benchs que dis tu de celui l� :
http://www.eweek.com/article2/0,3959,293,00.asp

oui enfin il date de plus d'un an ce bench donc il ne veut plus dire grand chose (depuis ibm a sortie db2 8.0) .
En plus j'ai l'impression que le test traite de petits volumes de donn�e (mais peut etre que je me trompe j'avoue avoir lu l'article en diagonale ) ... j'ai cru lire 200 000 lignes . Ce qui serait tout a l'avantage de MySql et au d�savantage d'Oracle, db2 qui ne sont pas optimis�s pour les petites bases de donn�es .

[vanquish]

oui enfin il date de plus d'un an ce bench donc il ne veut plus dire grand chose En plus j'ai l'impression que le test traite de petits volumes de donn�e

Je ne cherche pas � dire que mySQL est le meilleur des meilleurs.
Juste que si MySQL a un an de retard sur les + grand ce n'est pas si grave et qu'il n'est de toute fa�on pas si ridicule.

Je trouve que tu as la dent trop dure contre mySQL.
A te lire, il est proprement innutilisable.
Si c'�tait le cas, je ne pense pas qu'il aurait tant de d�fenseurs.
Certes ils ne sont pas tous objectif et on frise parfois la guerre de religion, je suis d'accord.

Mais je pense que tu penches trop dans l'autre sens et que tu te montres parfois un brin puriste.

Je ne suis pas un acharn� de mySQL.
Je ne le pratique pas depuis si longtemp et surtout pas en exclusivit�.
Je travaille essentiellement sous Windows et j'ai donc du limiter mes choix � FireBird, mySQL et sapDB, Postgress sous Cygwin pr�sentant visiblement des probl�me de stabilit� (aux lires que j'ai pu faire sur les forums).
Sinc�rement je trouve qu'ils ont tous avantages et inconv�nients et mon programme se connecte � n'importe lequel des trois.


Pour revenir sur le bench, il parle de 50.000 commandes avec 200.000 items associ�.
Tout d�pend si on doit comprendre 50x200 ou 50+200.
Mais je ne pense pas qu'il ai �quip� les serveurs de 4Go de RAM pour lire une table de 200.000 lignes.

Enfin, tu n'as pas r�pondu � ma question sur les transactions.
En quoi les transaction de MySQ/InnoDB sont-elles de fausses transactions ? En tout cas, je les trouve largement sufisantes pour les besoins.

Sinc�res Salutations
Gabriel

[alex2205]

PostgreSQL est fantastique, il g�re tr�s bien les proc�dures stock�es.

Je conseille PostgreSQL par rapport � Mysql, enfin cela d�pend des besoins, mais dans l'avenir, tu ne sait pas si tu n'auras pas besoin de tous ceci :

- faire des requ�tes ensemblistes (UNION, EXCEPT, INTERSECT)
- faire des sous requ�tes
- faire des triggers
- g�rer l'int�grit� r�f�rentielle
- faire des proc�dures stock�es
- faire des fonction utilisateurs

[vanquish]

Utilisateurs MySQL :

Westone Laboratories , 1.5 millions d'enregistrements 65.000 nouveaux/mois
Texas Instrument, plusieurs millions de requ�tes/jours
Le site de la NASA : 300.000 hits /mois
Yahoo ! Finance : base de donn�es de 25 Giga
Select Bourse : 1200 insert /seconde , 2 bases de 26 Giga
Mytrix Inc : 1 TeraByte de donn�es.
French stock exchange tracking system 800 requ�te /seconde en moyenne.

Ok, ok ... Postgress est fonctionnellement plus avanc� de mySQL. Je suis tout � fait d'accord !

Je ne fait pas une religion de mySQL.
Par exemple l'aspect "sauvegarde � chaud" n'est pas g�niale.

C'est pourquoi j'utilise aussi FireBird et d�s que Postgress SQL sera dispo sous Win32, promis je m'y met.

Mais faudrait quand m�me en finir avec les perpetuelles exag�rations quand � l'inefficacit� de mySQL.

Visiblement tout un tas de gens tr�s professionnels se contentent de cette solution !

De plus une comparaison point � point n'a pas de sens si elle est sortie de tout contexte.

Un camion de 38 tonnes est plus grand, plus puissant, plus s�curisant en cas d'accident et poss�de un plus gros volume utile que ma voiture et pourtant c'est de loin la pire des solutions pour ce qui est d'aller au boulot chaque matin.
Ma voiture est beaucoup plus adapt�e.
Enfin c'est un avis tr�s personnel ....
Parce que, pour aller au boulot, c'est pr�cisemment un 38t qu'utilise mon beau p�re tous les matin. Faut dire qu'il est routier.

Le contexte .... Le contexte ....

MySQL � de gros d�faut et de grosses limites mais aussi d'�normes qualit�s, comme sa facilit� de d�ploiement et de param�trage, sa disponibilit� sur toutes les plattes-formes ....

Pour ce qui de l'usage professionnel : la possibilit� de prendre un contrat d'assistance directement aupr�s des d�veloppeurs est beaucoup s�curisante que de n'avoir comme comme support que des forums o� �ventuellement quelqu'un tentera de r�pondre � votre question. Quand on est dans un milieu o� l'ouverture de parapluie est la r�gle ce n'est pas un d�tail.

[el muchacho]

L'enregistrement des noms de domaine .org et .info sont g�r�s depuis 2002 par le consortium Afilias sur des bases PostgreSQL (qui a remplac� Oracle). Pour les .org, la base fait 65 T�ra octets, et �a a l'air de bien marcher.

Si ce n'est pas un gage de solidit�, �a...

Mais MySQL sait aussi traiter de grandes masses de donn�es plusieurs dizaines ou centaines de Go.
En fait, pour r�aliser de grosses base de consultation (biblioth�ques de mol�cules, d'articles, de brevets, etc, ou bien un forum sur le web), MySQL est parfaitement adapt� et les tests qu'on trouve sur le net montrent que c'est l'un des SGBD les plus rapides avec Oracle. Par contre, ses d�ficiences ne le destinent pas � des applications complexes comme des r�servations d'hotel par exemple.
Tout est question d'application.

[jmmolina]

J'utilise MySQL au jour le jour et je ne m'int�resse � PostgreSQL que depuis le probl�me rencontr� par SourceForge avec MySQL, voir plus loin. Je d�veloppe aussi bien des applications web (Sites, intranet...) que des logiciels qui utilisent principalement MySQL comme SGBDR. Un peu de SQLite pour les bases locales ou de PostgreSQL pour l'h�ritage de tables. Vous l'avez compris mon c�ur bat un peu plus pour MySQL que pour PostgreSQL, que je connais moins bien �videmment. Cependant je ne me suis jamais retrouv� dans une impasse malgr� les quelques questions que certaines limitations de MySQL peuvent soulever. Toutefois ces limitations ne devraient pas g�ner certains d�veloppeurs, un bon cahier des charges pr�vient souvent tous les maux. Comme quelqu'un l'indiquait, c'est le contexte qui importe, dans quel cadre tel ou tel SGBD sera utilis�.

Avantages de MySQL :

• Large communaut� de d�veloppeurs (PHP).
• Excellente documentation. En plusieurs formats (HTML, HTML Help...), en ligne avec commentaires.
• De tr�s nombreux didacticiels et articles pour tout savoir sur MySQL, et PHP.
• R�plication et sauvegarde de bases. Gestion d'une simple r�plication ma�tre-esclave dans le cas d'une sauvegarde par exemple.
• Gestion de certaines contraintes d'int�grit� : Cl�s �trang�res pour les tables InnoDB par exemple.
• Base locale : Possibilit� d'embarquer MySQL dans un logiciel et de le distribuer sans serveur. Un peu comme BDE de Borland je crois ou encore SQLite (Distribu� avec PHP5).
• Gestion des transactions (BEGIN, COMMIT/ROLLBACK).
• phpBB : Le forum utilis� par Developpez.com, comme par plusieurs centaines d'autres sites, utilise MySQL (J'aimerai bien conna�tre la taille de la base !).
• MySQL est support� par la majorit� des h�bergeurs gratuits, ce qui n'est pas le cas de PostgreSQL.
• D'excellents outils pour administrer vos bases : PhpMyAdmin pour le web par exemple.
• Simple � installer et configurer, d�ployer et maintenir sous Windows.
• Bon support pour les professionnels d'apr�s la seule et unique exp�rience que j'ai pu avoir, concernant l'embarquement d'une base MySQL dans un logiciel notamment. �quipe tr�s r�active.
• Le petit dernier qui n'est pas forc�ment un avantage mais plus une fonctionnalit� bienvenue, la fonction LAST_INSERT_ID() qui permet de r�cup�rer l'identifiant, la valeur de la cl� primaire AUTO_INCREMENT, de la derni�re entr�e ins�r�e dans une table par un INSERT. Avec PostgreSQL il faut utiliser les s�quences.

Inconv�nients :

• N'est plus utilis� par SourceForge car MySQL ne supportait pas les mont�es en charge, ils ont opt� pour PostgreSQL. MySQL est donc peut-�tre tr�s simple � installer et d�ployer mais il n'atteint peut-�tre pas le degr� de scability de PostgreSQL.
• Non support de la norme SQL2 (92) � 100%. � vrai dire je n'ai jamais rencontr� de probl�mes pour l'�criture de mes requ�tes, il suffit de prendre quelques heures pour lire les premiers chapitres du manuel et voir que MySQL ne s'en �loigne pas tant que �a, sauf pour les puristes .
• Des limitations peuvent g�ner certains d�veloppeurs : D�clencheurs, proc�dures stock�es... Avec MySQL il faut d�placer la logique SGBD au niveau de son application, ce qui est forc�ment moins optimum que de laisser le SGBD le faire. On peut tout faire avec un langage de script comme PHP par exemple (Gestion des contraintes d'int�grit�, effacements en cascade...) mais il vaut toujours mieux avoir recours aux fonctionnalit�s avanc�es si elles sont disponibles, c'est le cas de PostgreSQL : Afin de s�parer la logique applicative de la logiquement purement B�d�d�tionnelle :p. Un peu comme on utilise des mod�les pour s�parer la logique applicative de la logique de pr�sentation.

Avantages de PostgreSQL :

• H�ritage de tables : PostgreSQL n'est donc pas qu'un simple SGBDR. C'est le principal argument que je peux avancer car c'est la seule fonctionnalit� qui me manque dans MySQL.
• Scability : Voir le probl�me de SourceForge avec MySQL.
• Toutes ces fonctionnalit�s avanc�es dont certains d�veloppeurs ne peuvent plus se passer : Sous requ�tes, d�clencheurs et proc�dures stock�es principalement.

Inconv�nients :

• Non disponible en natif pour Windows, il utilise une couche d'�mulation (CygWin). La version 8 � venir sera disponible en natif pour Windows.
• Ne peut pas g�rer une base locale, mais je peux me tromper. Un avis des experts ? Apr�s on peut dire qu'il n'a pas �t� concu pour, mais opter pour MySQL et vous aurez le meilleur des 2 mondes, le local et le en ligne.
• Voir certains avantages de MySQL : Moins support� par la communaut� des d�veloppeurs PHP (Encore faut-il savoir � quelle cat�gorie vous appartenez), on trouve plus d'h�bergeurs PHP/MySQL mais les grandes pointures proposent tr�s souvent PostgreSQL (Peut-�tre plus co�teux � d�ployer que MySQL car plus gourmand en ressources...).

Quelles sont les diff�rences entre MySQLl et postgreSQL ?

Pour r�sumer je dirai que MySQL est accessible et peut convenir � la majorit� des applications que le commun des mortels pourrait en avoir. Par contre PostgreSQL propose bien plus de fonctionnalit�s (Proc�dures stock�es, d�clencheurs...) mais ne conviendra pas forc�ment � tout le monde, aux d�veloppeurs Windows qui d�couvrent PHP ou les bases de donn�es par exemple. Apr�s, comme je l'ai dit auparavant, le langage de programmation utilis� peut parfaitement prendre le relai et s'occuper de g�rer la logique de votre base, � la place des proc�dures stock�es, d'impl�menter des d�clencheurs, pour effacer en cascade par exemple... Tout est possible mais n'oubliez jamais que cela a forc�ment un co�t en terme de performances, plus c'est fait en amont, au niveau du SGBD, plus c'est bon... .

Pourquoi choisir l'un ou l'autre?

Choisir MySQL pour du d�veloppement web aussi bien sous Linux que Windows. Free.fr propose par exemple un espace de 100 Mo pour h�berger son site, support PHP/MySQL compris. Choisir MySQL pour int�grer un SGBDR � un logiciel afin de le distribuer, tout comme on pourrait le faire en choisissant SQLite ou n'importe quel autre SGBDR capable de g�rer une base locale (On parle aussi de SGBD fichier).

Choisir PostgreSQL si vous avez besoin d'un SGBDOR capable de g�rer l'h�ritage de tables. Notez tout de m�me qu'on peut s'en passer en adaptant sa d�marche de conception et d'impl�mentation, mais c'est comme de dire que tout ce qui peut �tre fait en C++ peut l'�tre en C . Choisir PostgreSQL si vous ou votre projet ne pouvez pas vous passer de ses fonctionnalit�s avanc�es : Proc�dures stock�es, requ�tes imbriqu�es...

Notez quand m�me que mes arguments en faveur de MySQL n'implique pas forc�ment que PostgreSQL n'est pas capable de g�rer la r�plication d'une base ou ne propose pas d'outils pour administrer vos bases, loin de l�. Simplement comme ces fonctionnalit�s sont disponibles sous MySQL et qu'elles fonctionnent tr�s bien, je n'ai eu aucune raison d'aller voir ailleurs dans le cadre des projets sur lesquels j'ai travaill�s.

Donc choisissez le SGBD qui r�pond le mieux � vos besoins et non pas � ceux des autres. J'ai bien aim� l'exemple du camion, je pense qu'il faut aller dans ce sens l�. Une autre analogie, tir�e de mon activit� c�r�brale journali�re passionnante, on a pas forc�ment besoin d'ouvrir OpenOffice pour �crire 2 lignes dans un fichier texte, on peut se contenter d'ouvrir bloc-notes . Toutes ces ann�es de m�ditation pour comprendre que la r�ponse peut parfois se trouver dans les choses les plus simples .

[Invit�]

mes quelques exp�riences.

Je d�veloppe depuis 4 ans sur diff�rents SGBD(R) ... (Access, Oracle, MySQL, postgreSQL, SQL Server), j'ai donc rencontr� diff�rents probl�mes pour l'un ou l'autre de ces SGBD.

Je ne veux pas en faire l'�talage ici, puisque ce forum compare MySQL et PostgreSQL.

Pour toutes les personnes utilisant MySQL v < 4, n'oubliez pas que cet un SGBD ! il n'y a que les tables Inno DB qui tentent d'impl�menter une premi�re version des relations entre table.

Pourquoi MySQL n'est pas nativement relationnel :
il faut pour cela regarder un peu sa mise en place sur server. chaque table correspond � un fichier. Autrement dit, un select sans jointure, correspond � en gros un find dans un fichier, ce qui rend pour �a mysql tr�s rapide !

PostgreSQL est bas� sur un autre syst�me, il est donc un peu plus lent ... puisque doit checker tout un ensemble de param�tres : trigger, regles, vues ... (mais il est possible aussi de laisser un max de choses en m�moires en customisant un peu le server)

J'ai d�velopp� un site enti�rement avec PostgreSQL, il y avait quelques workflow � impl�menter, plutot q de me prendre la tete avec des scripts cgi, j'ai utilis� les triggers.
ce que mysql ne sait pas faire, puisqu'il n'a pas �t� pens� pour non plus.

Ce que j'aime � dire aux personnes qui arrivent dans ma soci�t�, c'est que MySQL est � utiliser dans plusieurs cas (au dela des besoins trigger et autre) :
- si tu n'as pas de grosses contraintes relationnelles
- pas de grosses recherches multi criteres avec plusieurs tables.
- ...

PostgreSQL pour tout le reste.

Il faut savoir aussi, que la version de mysql 4 s'oriente vers le SGBDR ! ... et implemente une chose g�niale (enfin) la maj/suppression en cascade qui pour n'importe quel DBA lui garantit que les contenus de sa base sont p�rennes.


enfin, c'est un peu comme compar� diff�rents langages entre eux, il ne faut pas oublier leur but premier.


M�me si j'adore postgreSQL parce qu'il me permet d'�viter pas mal de codes cgi, mysql n'est pas non plus � jeter ! ... au contraire, au vue de ces �volutions j'en viens � me perdre entre sa finalit� et celle de maxDB ... aidez moi ...

[BuLma]

Pour avoir utilis� les 2 je peux dire que ce qui m'a vraiment manqu� chez MySQL dans une des applications Web que j'ai d�velopp�, c'est les contraintes d'int�grit� mais aussi les vues. Car, � partir du moment o� l'on commence � avoir des jointures dans tous les sens, c'est quand m�me plus pratique d'avoir des triggers et des vues pour �claircir le bourrier.

Donc au final, pour une appli qui demande beaucoup de relationnel, je pr�f�re largement PostGreSQL .

Sinon, pour des petits sites Web relativement simple, MySQL suffit amplement et surtout est propos� par la plupart des h�bergeurs, contrairement � PostGreSQL

Bref, comme dit si bien plus haut, tout d�pend de l'appli � d�velopper

[eClaire]

Bonjour,

C'est un topic qui me convient � merveille mais je n'y ai pas trouv� ma r�ponse.

Mon crit�re de choix se porte sur la finesse des verrous pos�s sur les tables. Je crois que pour Mysql, toute une table est bloqu�e alors que pour PostGr�s, il est plus fin.

Avez vous des connaissances concernant cette particularit�?

[SQLpro]

Voici un test int�ressant entre MySQL, PostGreSQL et DB2.

Attention, le test est orient� traitement des nombres (astronomie).

http://wiki.astrogrid.org/pub/Astrog...ning/cross.htm

A +

[Maximil ian]

Un comparatif int�ressant sur le sujet, doubl� d'un test de performances avec ses sources.

[kedare]

vu la sortit de mysql5
que fait PostgreSQL et pas Mysql ?

[Maximil ian]

Langage proc�dural plus avanc� avec support de plusieurs langages de programmation
Triggers et vues plus avanc�s (triggers peu utilisables sous MySQL)
R�les
Partitionnement de tables
Index bitmap
...

[SQLpro]

En terme de respect de la norme SQL PostgreSQL en est tr�s pr�s et MySQL tr�s �loign�. Cela � son importance et pour deux raisons :
1) la portabilit� (ce n'est d'ailleurs pas pour moi le crit�re le plus important)
2) l'intelligence relationnelle (�a c'est plus important !)

Quand je voit des op�rateurs anti relationnel dans mySQL comme LIMIT ou des types de donn�es qui n'existe pas en SQl comme INT(2) je trouve que c'est de la m�me nature que ce qui � conduit IBM a �tre �cart�s par certains informaticiens : des trucs sp�cifiques, incongrus, inutiles, contre performants et dangereux afin de capter un march� et d'enferrer les utilisateurs sur MySQL.

De plus le niveau transactionnel de MySQL est loin d'�tre satisfaisant alors que celui de PostGreSQL est m�me en avance sur Oracle ou SQL Server.

De fait mon choix est vite fait, entre un gestionnaire de fichiers encapsulant du SQL et qui vient de se mettre r�cemment � faire (p�niblement) des transactions et un vrai SGBDR transactionnel il n'y a pas photo, PostGreSQL et pas MySQL !

A +

[Marc Lussac]

Ce d�bat � �t� largement mod�r�, ont �t� supprim�s les propos HS, faux ou obsoletes.

_________________________________________________________
Notes de la mod�ration

Avant de participer au d�bat, merci de commencer par lire le d�bat

Merci de nous faire partager vos exp�riences r�elles

Si vous n'avez pas d'exp�rience sur MySQL ou postGreSQL, merci de ne pas participer au d�bat pour reproduire des propos faux recueillis sur des forums amateurs, ou des propos obsol�tes sur des anciennes versions.

Les propos d�nigrants ou diffamatoires sur ces deux SGBD (post�s g�n�ralement par des amateurs inexp�riment�s) seront supprim�s � vue. Ces deux produits quoi que diff�rents sont tous les deux des produits de qualit�s utilis�s par des professionnels sur des sites de tr�s grande envergure.

[Marc Lussac]

Une petite note personnelle.

Ceux qui tentent vainement de d�nigrer MySQL se trompent tr�s lourdement

Pourquoi la tr�s grande majorit� des h�bergeurs proposent avant tout MySQL ?

R�ponse : De tr�s nombreux benchs ont �t� fait qui prouvent que MySQL propose des performances exceptionnelles dans de nombreux cas d'utilisation, notament les cas d'utilisation simples les plus courants. De plus, dans le cas ou les transaction ne sont pas n�cessaires (et oui ca existe, tous le monde n'� pas � d�velopper un syst�me bancaire) , MySQL sans les transactions donne pour de nombreux cas d'utilisations des performances exceptionnelles, voir parfois devant les SGBD payants poids lourd du march�.

Enfin MySQL consomme tr�s peu de ressources m�moire et CPU, ce qui est un avantage colossal quand vous devez mettre en batterie une s�rie de petits serveurs pour tenir globalement une charge �norme (exemple ebay).

Donc oui postGreSQL apporte des fonctions en plus de MySQL, et vous pouvez choisir PosgreSQL si vous avez besoin des ces fonctions.

Mais tout ceux qui �crivent que MySQL ne tiens pas la charge de trompent totalement, dans beaucoup de cas d'utilisation simples, MySQL est carr�ment le meilleur, et est parfois jusqu'� 2 fois plus rapide que tous les autres SGBD !

Chaque cas d'utilisation est diff�rent, et les r�sultats seront � chaque fois diff�rents selon le cas d'utilisation et les conditions de production.

Par exemple si vous avez une machine avec peu de RAM, ou mis en batterie 1000 machines avec peu de RAM (ce qui est tr�s int�ressant �conomiquement parlant), MySQL sera sans doute la solution qui vous donnera toujours les meilleures performances et le cout le plus bas, car tous les autres SGBD ont besoin de beaucoup plus de ressources.

Mon avis est donc le suivant :

- PotsGreSQL est un excellent SGBD, � conseiller (raisons d�j� cit�es plus haut)
- MySQL est un SGBD extr�mement int�ressant dans certaines conditions d'utilisation et de mise en production car il permet de fournir un tr�s grand nombre de requ�tes et ce pour un cout tr�s bas. Si par hasard vous avez d�cid� d'utiliser un SGBD sans les transactions pour une application en particulier, dans ce cas MySQL est imbatable et peu fournir jusqu'� 2 fois plus de requetes que tous les autres SGBD sur des machines comparables. (d'ou son succ�s chez les h�bergeurs, et d'ou son utilisation sur certains sites �normes).


Si vous pensez que PostGreSQL est meilleur que MySQL ou l'inverse vous vous trompez totalement, et d'accuser l'incomp�tence des utilisateurs pour leurs choix est une preuve d'ignorance et d'incomp�tence pure. Les deux SGBD ont leurs utilisateurs satisfaits tout simplement car ils sont diff�rents et ont chacun leurs forces.


PS : Par exemple dans ce test MySQL (avec transactions /innodb) est deux fois plus rapide que PostgreSQL. Attentions des bench peuvent donner des r�sultats totalement oppos�s �a d�pend de ce qui est test� et des conditions de tests.

[jnore]

Bonjour

Je suis utilisateur de PostgreSQL.
Pourquoi?
J'ai d�marr� une base mise en r�seau au d�part sous access.
Au vu des performances et des donn�es cons�quentes qu'il m'a fallu g�rer, cela devenait insoutenable.
Il m'a fallu donc m'orienter vers un Sgbd plus performant mais tout en gardant l'acc�s aux donn�es via les formulaires access et l'odbc.
J'ai voulu dans un premier temps m'orienter vers mysql.
L'insertion des tables s'est fait sans probleme mais quelle surprise lorsqu'il m'a fallu lier toutes mes vues vers access. C'�tait tout et n'importe quoi.
J'avis des champs de tronqu�s ainsi que des nbres de lignes qui ne correspondaient en rien au r�sultat souhait�!!!

Je me suis orient� directement sur Postgresql dont on parlait d�j� � l'�poque.
Le r�sultat fut sans appel
Le pilote odbc est vraiment de qualit�. J'ai travaill� plusieurs ann�es avec et je n'ai jamais eu de souci sur les donn�es transmises.
Certes ce n'est pas mysql m�me que je remets en question mais son outil de liaison. Je crois aussi que c'est un crit�re de selection surtout si l'on a peu de temps � perdre.

Cependant dans le cadre de d�veloppement web avec le couple Mysql/php il est �vident que la mise en oeuvre de cette solution est souvent la plus ais�e.
Malgr� cela je conserve Postgresql qui est aussi tr�s bien g�r� en PHP.