Voila mon probleme, je dois mettre en place une base de données chez un client, sous MacOS X. Je me pause la question suivante : quel est le meilleur SGBD sous macos X, Postgres ou MySQL ?
Il va falloir etre un peu plus précis sur tes besoins :
- type d'accès privilégié ? 98% de lecture 2% écriture ou plutot 50/50 ?
- besoin de fonctionnalités telles les clés étrangeres, les transactions, les subquery ...
- besoin en terme de charges
techniquement je suis tenté par dire que si tu n'as pas besoin de choses évoluées (transaction et autres), que tu fais principalement de la lecture alors mysql est un bon choix.
(je ne parle pas particulierement face à macosX mais étant sur base unix ca ne devrait pas etre différent d'ailleurs)
et non ...
ne me demande pas pourquoi mais c'est comme ca, des histoires de locks à mon souvenir.
Toujours est'il que en écriture il n'est pas fortiche, et que avec les transactions c'est désastreux. Enfin c'est ce que j'avais retenu la derniere fois que j'avais regardé (ce qui n'est pas si vieux vu qu'il y avait le support des transactions)
Pour les histoires de lock tu dois parler des accès concurrents en lecture et écriture sur une même table. Effectivement c'est quelque chose que MySQL ne sait pas faire (avec les tables par défaut). Par contre si tu modifies souvent une table qui est très peu consultée, les écritures sont très rapides. Il faut aussi penser à regrouper plusieurs écritures en une seule pour accélérer encore les choses. Il y a même moyen d'optimiser encore plus en n'écrivant les index sur le disque que lors du vidage du bout de cache correspondant (option DELAY_KEY_WRITE).
Pour les transactions il y a des benchs ici (mais ils sont faits par l'auteur des transactions sous MySQL...) : http://www.innodb.com/bench.html(...) . J'ai essayé les tables transactionnelles sur ma propre appli au boulot, ça s'approche à 10 ou 20% près des performances des tables par défaut (non-transactionnelles). Par contre ça prend beaucoup plus d'espace disque, ce qui est normal mais dissuasif dans mon cas précis.
Je considère que çà tourne de la même façon sous Linux que sous MacOS X.
> quel est le meilleur SGBD sous macos X, Postgres ou MySQL ?
Pour de petites choses, les deux sont assez proches. Çà peut-être de petites choses mais une grosse base de donnée. Je parle de complexité.
Pour des projets complexes, PostgreSQL est clairement meilleur :
- sous requête (mieux que MySQL).
- view et possibilité d'affiner les protection par view.
- de très nombreux types pour pratiquement tout les cas d'utilise. Type date étendu, type exotique comme adresse ip, point, etc...
- possibilité de définir de nouveau type et des nouveaux opérateurs.
- orienté objet (pas toujour utile ...)
- une bonne conformité SQL92.
- language embarqué.
- trigger.
- possibilité d'intégré des fonctions C pour les triggers, fonctions, etc... un peu complexe.
- contrôle d'intégrité complet. Par exemple la suppression d'un enregistrement supprime tous les enregistrements dépendants par exemple.
- grosse capacité d'optimisation. Rules. Index très souple avec le choix des fonction d'hachage.
- support multi-lang : 1,2 marche en français. Les date en français "vendredi 12 janvier 2002".
- Vrai système de transaction et pas seulement sur une seul table.
- versionning (complexe).
- backup à chaud.
- rapide compte-tenu de sa configuration. Tout transaction validée est définitivement écrite sur le disque.
- rapide sous forte charge avec beaucoup d'écriture et lecture.
- Bonne documentation.
Par contre c'est parfois un peu difficile à cerner (par exemple les changement de type).
Bouffe plus de mémoire que MySQL. Pour l'admin c'est un peu plus compliqué que MySQL. En utilisation avec un serveur web et connection persistante et utilisation de plusieurs comptes PostgreSQL çà peut bouffer beaucoup, beaucoup de mémoire. En suprimant les connextions persistante c'est un poil moins rapide mais plus léger.
Par contre mysql offre la possibilité de fixer des quota par base de donnée. Chaque base de donnée étant dans un répertoire, on peut utiliser chmod g+s et fixer un quota sur le groupe.
Pour moi PostgreSQL est meilleur que MySQL. Mais çà dépend du projet. Dans la majorité des cas et pour beaucoup de développeurs MySQL est suffisant.
# Re: PostgreSQL ou MySQL ?
Posté par Éric (site web personnel) . Évalué à 6.
- type d'accès privilégié ? 98% de lecture 2% écriture ou plutot 50/50 ?
- besoin de fonctionnalités telles les clés étrangeres, les transactions, les subquery ...
- besoin en terme de charges
techniquement je suis tenté par dire que si tu n'as pas besoin de choses évoluées (transaction et autres), que tu fais principalement de la lecture alors mysql est un bon choix.
(je ne parle pas particulierement face à macosX mais étant sur base unix ca ne devrait pas etre différent d'ailleurs)
[^] # Re: PostgreSQL ou MySQL ?
Posté par Moby-Dik . Évalué à 1.
[^] # Re: PostgreSQL ou MySQL ?
Posté par Éric (site web personnel) . Évalué à 3.
ne me demande pas pourquoi mais c'est comme ca, des histoires de locks à mon souvenir.
Toujours est'il que en écriture il n'est pas fortiche, et que avec les transactions c'est désastreux. Enfin c'est ce que j'avais retenu la derniere fois que j'avais regardé (ce qui n'est pas si vieux vu qu'il y avait le support des transactions)
pas de lien la dessus sous la main, dsl
[^] # Re: PostgreSQL ou MySQL ?
Posté par Moby-Dik . Évalué à 3.
Pour les transactions il y a des benchs ici (mais ils sont faits par l'auteur des transactions sous MySQL...) : http://www.innodb.com/bench.html(...) . J'ai essayé les tables transactionnelles sur ma propre appli au boulot, ça s'approche à 10 ou 20% près des performances des tables par défaut (non-transactionnelles). Par contre ça prend beaucoup plus d'espace disque, ce qui est normal mais dissuasif dans mon cas précis.
[^] # Re: PostgreSQL ou MySQL ?
Posté par Moby-Dik . Évalué à 2.
# Re: PostgreSQL ou MySQL ?
Posté par 123neveu . Évalué à 10.
> quel est le meilleur SGBD sous macos X, Postgres ou MySQL ?
Pour de petites choses, les deux sont assez proches. Çà peut-être de petites choses mais une grosse base de donnée. Je parle de complexité.
Pour des projets complexes, PostgreSQL est clairement meilleur :
- sous requête (mieux que MySQL).
- view et possibilité d'affiner les protection par view.
- de très nombreux types pour pratiquement tout les cas d'utilise. Type date étendu, type exotique comme adresse ip, point, etc...
- possibilité de définir de nouveau type et des nouveaux opérateurs.
- orienté objet (pas toujour utile ...)
- une bonne conformité SQL92.
- language embarqué.
- trigger.
- possibilité d'intégré des fonctions C pour les triggers, fonctions, etc... un peu complexe.
- contrôle d'intégrité complet. Par exemple la suppression d'un enregistrement supprime tous les enregistrements dépendants par exemple.
- grosse capacité d'optimisation. Rules. Index très souple avec le choix des fonction d'hachage.
- support multi-lang : 1,2 marche en français. Les date en français "vendredi 12 janvier 2002".
- Vrai système de transaction et pas seulement sur une seul table.
- versionning (complexe).
- backup à chaud.
- rapide compte-tenu de sa configuration. Tout transaction validée est définitivement écrite sur le disque.
- rapide sous forte charge avec beaucoup d'écriture et lecture.
- Bonne documentation.
Par contre c'est parfois un peu difficile à cerner (par exemple les changement de type).
Bouffe plus de mémoire que MySQL. Pour l'admin c'est un peu plus compliqué que MySQL. En utilisation avec un serveur web et connection persistante et utilisation de plusieurs comptes PostgreSQL çà peut bouffer beaucoup, beaucoup de mémoire. En suprimant les connextions persistante c'est un poil moins rapide mais plus léger.
Par contre mysql offre la possibilité de fixer des quota par base de donnée. Chaque base de donnée étant dans un répertoire, on peut utiliser chmod g+s et fixer un quota sur le groupe.
Pour moi PostgreSQL est meilleur que MySQL. Mais çà dépend du projet. Dans la majorité des cas et pour beaucoup de développeurs MySQL est suffisant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.