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.