Discussion :

[agi.v]

Bonjour à tous,
J'ai un projet qui va être amené à prendre de l'envergure.
Il s'agit de multiples applications (Web et Desktop) partageant des informations (dans le respect de la vie privée).
Ma demande (plutot qu'une question) concerne les avantages et défauts de MySQL et postgresql (deux SGBDR qui me tente bien).
Donc selon vous, pour un nombre important de lecture/écriture tous les jours le quel des deux choisiriez vous ? Argumenter s'il vous plait.

Merci

[SQLpro]

Ce sont deux SGBDR qui ne sont pas destiné à des application dont l'envergure est l'entreprise, mais dédié aux particuliers et TPE…
1) MySQL il ne faut pas lui en demander beaucoup et la liste des bugs est impressionnantes. Le réserver au max à quelques dizaines d'utilisateurs et moins d'une centaines de Go….
A lire sur les dangers de MySQL :
https://sqlpro.developpez.com/tutori...mysql-mariadb/
2) PostgreSQL est déjà beaucoup plus taillé pour des solutions allant du particulier à la PME (ne pas dépasser en pratique 100 user et quelques centaine de GO

A +

[agi.v]

Bonjour SQLPRO,
Merci de votre réponse et de la documentation que je vais lire. Je ne savais pas du tout que MySQL était si "mauvais".
Pour une application pouvant avoir environs 500 utilisateurs quel SGBDR gratuit me recommanderiez vous ?
Y a t-il ici d'autres personnes partageant cet avis ?

Merci

[xdelatour]

Bonjour,

Quand on voit la liste des clients de MySQL, on se dit tout de suite que c'est effectivement hyper dangereux !

[agi.v]

Bonjour xdelatour,
Merci pour votre message. Le nombre de clients très connu est en effet parlant. Du coup si des sociétés comme elles font confiance a MySQL pourquoi Mysql serait mauvais selon vous @sqlpro ?
@xdelatour selon vous quel SGBDR serait le mieux pour une application Web d'environs 500 clients voire plus ? Je parle autant en vitesse qu'en stabilité.
Je commence à utiliser postgresql et ce SGBDR possède plein d'outils très intéressants. Quel est votre avis ?

Merci

[xdelatour]

Je ne connais pas postgresql mais effectivement il est davantage conseillé que MySQL pour de gros projets. En tout cas je ne pense pas que MySQL soit aussi mauvais que ça, après tout beaucoup de sites Wordpress tournent avec, mais c'est vrai que j'ai constaté que certains produits l'ont abandonné.

[agi.v]

Merci de votre réponse @xdelatour
Puis-je me permettre de vous demander ce que vous utilisez comme SGBDR ?
Et selon vous quels en sont les avantages et défauts ?
Merci

[xdelatour]

A titre personnel j'utilise MariaDB pour un site perso, et c'est aussi ce que j'avais installé dans un cadre professionnel pour utiliser GLPI/OCS Inventory.

Mais avec d'autres personnes nous nous installons un serveur avec de grosses applications qui nécessitent Postgresql : rocket.chat, GitLab et j'envisage d'y ajouter une instance SonarQube. C'est à ce dernier que je faisais allusion plus haut : le support MySQL a été abandonné.

Pour les avantages, je trouve MySQL simple et léger, et en tout cas suffisant pour mes besoins (un petit site avec seulement 20000 enregistrements).

[SQLpro]

Bonjour xdelatour,
Merci pour votre message. Le nombre de clients très connu est en effet parlant. Du coup si des sociétés comme elles font confiance a MySQL pourquoi Mysql serait mauvais selon vous @sqlpro ?
@xdelatour selon vous quel SGBDR serait le mieux pour une application Web d'environs 500 clients voire plus ? Je parle autant en vitesse qu'en stabilité.
Je commence à utiliser postgresql et ce SGBDR possède plein d'outils très intéressants. Quel est votre avis ?

Merci

Il suffit de lire l'article....
Le nombre de client n'a rien à voir dans l'affaire. MySQL est un bricolage que l'on retrouve dans de nombreux produits bas de gamme, justement parce qu'il est gratuit ! Dès que l'on commence à attaquer de grosses volumétrie ou un nombre important d'utilisateur simultané MySQL est a fuir... Un simple exemple. Il existe des benchmarks officiels, ceux du TPC.... Ni MySQL ni MariaDB n'y figurent de peur du ridicule !
http://www.tpc.org/tpcc/results/tpcc_results.asp
http://www.tpc.org/tpce/results/tpce...ic_results=yes

Vous trouverez un nombre beaucoup plus important d'entreprises utilisant de l'Oracle ou du SQL Server....

A +

[SQLpro]

Je ne connais pas postgresql mais effectivement il est davantage conseillé que MySQL pour de gros projets. En tout cas je ne pense pas que MySQL soit aussi mauvais que ça, après tout beaucoup de sites Wordpress tournent avec, mais c'est vrai que j'ai constaté que certains produits l'ont abandonné.

Donc, vous ne connaissez pas PostGreSQL ni aucun autre SGBD apparemment, et vous en concluez que MySQL est très bon !
ça c'est de l'analyse comme j'aime !

A +

[SQLpro]

Et si vous voulez quelques comparatifs avec des tests de performances, voyez celui-ci :
https://sgbd.developpez.com/actu/873...par-Gugelhupf/
je cite :
"
Concernant l’écriture, PostgreSQL est très rapide et les performances affichées par MySQL sont juste aberrantes.
"

https://www.developpez.com/actu/9599...es-trois-SGBD/
http://phpdao.com/mysql_postgres_oracle_mssql/

A +

[RaphAstronome]

Bonjour,

Par "prendre de l'envergure" vous entendez quoi exactement ? La volumétrie ? Des centaines de Mo, des Go, centaines de Go, des To ?
Niveau complexité, les requêtes seront plutôt genre simples mais nombreuses (surtout un site à fort trafic) ou des gros traitements ?

Le terme "prendre de l'envergure" me fait un peu peur, c'est un coup à faire un truc hyper avancé et coûteux et au final c'est juste une petite base de données pépère.
Décrits plus ton projet, c'est vraiment pas possible d'être précis avec ce que tu donnes.

Sinon comme d'autres ici j'ai une nette préférence pour PostgreSQL.

MySQL pour avantage de pouvoir être pris en charge par les hébergements mutualisés (pour les petits sites web) et aussi par la plupart des CMS et autres services prets à mettre en place. Et encore sur ces deux points (surtout le second) cet intérêt est de moins en moins évident.

[StringBuilder]

Bonjour,

Quand on voit la liste des clients de MySQL, on se dit tout de suite que c'est effectivement hyper dangereux !

Tu veux que je te dises un truc ?

La liste des clients de Lotus est impressionnante aussi, on doit même y trouver des rois... mais c'est pas pour autant que ça sert à autrechose que se torcher le cul avec !

Il est tout à fait logique, et plus l'entreprise est grande, et plus c'est vrai, qu'un produit, aussi merdique soit-il, soit utilisé par de grands comptes : il suffit qu'un petit projet non critique développé par un stagiaire l'utilise, et on peut se targuer d'avoir la NASA comme client. C'est pas pour autant qu'on va retrouver le dit produit merdique dans les process critiques de calcul de trajectoire des fusées.

[StringBuilder]

Sinon, j'ai envie de dire : si le projet en est à se débuts, on se moque (un peu) du SGBD utilisé.

Utilisez un connecteur standard (ODBC par exemple) ou un langage qui permet de rendre générique le code d'accès aux données (par exemple C# qui permet d'utiliser des références à l'interface IConnection pour générer aussi bien des connexions SQLite, MySQL, Oracle, SQL Server ou PostgreSQL, aussi bien avec le connecteur natif, que ADODB ou ODBC.
Et surtout, écrivez vos requêtes avec du code SQL 100% standard, ainsi que les types de données manipulés.

Ainsi, si vous partez sur un SGBD, l'effort à fournir pour passer sur un autre sera relativement faible.
Même mieux, vous serez capable de faire tourner le même code avec plusieurs SGBD différents, ce qui peut être un plus si vous comptez distribuer votre solution, ou alors faire du SaaS "grand public" et du "professionnel" côte à côte.

[xdelatour]

Donc, vous ne connaissez pas PostGreSQL ni aucun autre SGBD apparemment, et vous en concluez que MySQL est très bon !
ça c'est de l'analyse comme j'aime !

A +

Je ne me souviens pas d'avoir écrit quelque part que MySQL est très bon, merci de ne pas me faire dire ce que je n'ai pas dit. Accessoirement j'ai également travaillé sur des bases de données Oracle. Je donnais juste mon avis sur MySQL, excusez-moi d'avoir empiété sur vos plates-bandes.

[CinePhil]

Le réserver au max à quelques dizaines d'utilisateurs et moins d'une centaines de Go

Bonjour Frédéric,

Quand tu parles de "quelques dizaines d'utilisateurs", tu veux dire "utilisateurs MySQL", je suppose ?

Le plus souvent, du moins dans ce que j'ai rencontré jusque là, une application accède au SGBD avec 1 utilisateur MySQL mais l'application peut avoir des centaines ou plus d'utilisateurs plus ou moins simultanés (actifs en même temps et lançant donc des requêtes sur le SGBD).
Même sur le PGI que j'administre et qui utilise Oracle, bien qu'il y ait de nombreux schémas (donc users Oracle), toutes les applications du PGI utilisent le même user Oracle. Et on nous demande de passer tous les patches SQL avec le même user Oracle.

Dans ma pratique, je crée un user MySQL par application. Il peut arriver que plusieurs users MySQL accèdent à la même BDD. Mais les volumes de données sont trèèèèès loin du Go !

Le problème vient-il :
- du nombre d'utilisateurs MySQL différents créés sur MySQL ?
- du nombre d'utilisateurs MySQL différents connectés simultanément sur MySQL ?
- du nombre de requêtes lancées sur une courte période, que ce soit par un ou plusieurs utilisateurs MYSQL ?

Tout ceci étant dit, et pour répondre à agi.v, je préférerais utiliser PostgreSQL que MySQL/MariaDB.

[agi.v]

Bonjour à tous !
Bon je vois que j'ai soulevé une question assez houleuse
Bon c'est un bon débat dans l'ensemble. Au risque de récolter les foudres de la communauté que pensez vous de mariadb par rapport a MySQL ? est ce mieux selon vous ? Pouvez vous donner des exemples ou des cas pratiques ?
Merci a vous tous !

[SQLpro]

Bonjour Frédéric,

Quand tu parles de "quelques dizaines d'utilisateurs", tu veux dire "utilisateurs MySQL", je suppose ?

Oui

Le plus souvent, du moins dans ce que j'ai rencontré jusque là, une application accède au SGBD avec 1 utilisateur MySQL mais l'application peut avoir des centaines ou plus d'utilisateurs plus ou moins simultanés (actifs en même temps et lançant donc des requêtes sur le SGBD).
Même sur le PGI que j'administre et qui utilise Oracle, bien qu'il y ait de nombreux schémas (donc users Oracle), toutes les applications du PGI utilisent le même user Oracle. Et on nous demande de passer tous les patches SQL avec le même user Oracle.

C'est juste stupide. Une personne qui utilise une application devrait utiliser un USER SQL personnalisé. Dans SQL Server sous Windows tu peut d'ailleurs utiliser le compte système de l'utilisateur pour te connecter, ce qui permet au niveau de la sécurité d'avoir une traçabilité maximale... (RGPD)...

Dans ma pratique, je crée un user MySQL par application. Il peut arriver que plusieurs users MySQL accèdent à la même BDD. Mais les volumes de données sont trèèèèès loin du Go !

Le problème vient-il :
- du nombre d'utilisateurs MySQL différents créés sur MySQL ?
- du nombre d'utilisateurs MySQL différents connectés simultanément sur MySQL ?
- du nombre de requêtes lancées sur une courte période, que ce soit par un ou plusieurs utilisateurs MYSQL ?

Le plus souvent c'est le nombre d'accès simultané et en sus le nombre de requête simultanées. Le nombre d'utilisateur créé n'a aucune influence...

Tout ceci étant dit, et pour répondre à agi.v, je préférerais utiliser PostgreSQL que MySQL/MariaDB.

A +

[SQLpro]

Bonjour à tous !
Bon je vois que j'ai soulevé une question assez houleuse
Bon c'est un bon débat dans l'ensemble. Au risque de récolter les foudres de la communauté que pensez vous de mariadb par rapport a MySQL ? est ce mieux selon vous ? Pouvez vous donner des exemples ou des cas pratiques ?
Merci a vous tous !

Globalement pire....

Oracle est un professionnel des bases de données depuis plus de 40 ans.... depuis qu'il a repris MySQmerde il ne cesse de corriger les défauts, bugs et incohérence.
MariaDB c'est toujours la même équipe de bricoleur qui au lieu de corriger les bugs, fait une fuite en avant en ajoutant autant de module merdique dont la liste des bugs s'allonge démesurément !

A +

[StringBuilder]

C'est juste stupide. Une personne qui utilise une application devrait utiliser un USER SQL personnalisé. Dans SQL Server sous Windows tu peut d'ailleurs utiliser le compte système de l'utilisateur pour te connecter, ce qui permet au niveau de la sécurité d'avoir une traçabilité maximale... (RGPD)...

Malheureusement, cette pratique est particulièrement répandue pour plusieurs raisons :

Historique
La plupart des solutions PGI existaient déjà il y a plus de 30 ans. Leur socle technique, mais aussi et surtout leur modélisation et logique de fonctionnement a généralement peu évolué depuis. A cette époque, la plupart des outils de gestion de données ne géraient ni utilisateurs ni droits. A commencer par le séquentiel indexé, encore largement utilisé à cette époque.

Besoin fonctionnel
Généralement, les droits d'accès des utilisateurs sont gérés par paramétrage dans le PGI directement. En effet, madame Michu à la compta, elle a besoin de pouvoir accéder au module compta en lecture/écriture, à la gescom en consultation seulement sur certaines fonctions, tel onglet de la fiche client doit être modifiable mais pas les autres, etc. Et accessoirement, elle a le droit d'accéder à telle imprimante.
Une gestion aussi fine des besoins (jusqu'à la ligne/colonne, en fonction de critères métiers) est quasi impossible à mettre en place au niveau de la base de données, et surtout, l'administrateur du PGI souhaite gérer aussi bien les modules, lignes et écrans, mais aussi imprimantes directement dans un seul outil. Les droit niveau SGBD ne permettent pas de choisir quelle imprimante utiliser, ni qui doit être en copie cachée de tous les mails envoyés.

Besoin technique
La plupart des applications sont mono-utilisateur d'un point de vue droits.
Par exemple, si on se connecte tous les deux sur le site de vente d'Amazon, aucun intérêt d'avoir un utilisateur SQL pour toi et un pour moi : on a les mêmes droits, on accède aux mêmes écrans, etc. Donc un unique compte fait parfaitement l'affaire, et est bien plus simple à gérer qu'une myriade de comptes, d'autant que certains éditeurs font payer à l'utilisateur (par exemple, dans SQL Server, si on passe par les droits Windows, il faut un compte AD pour chaque utilisateur, ce qui peut rapidement chiffrer, surtout si le besoin d'un tel compte n'est justifié que par SQL Server - pas de TSE, pas de poste dans le domaine, etc. -).

Donc autant d'un point de vue SGBD pur, c'est plus ou moins stupide, autant pour les applications qui utilisent les SGBD ça ne se justifie pas forcément.
Avoir des utilisateurs types en fonction des profiles des utilisateurs finaux sera déjà plus logique, encore faut-il avoir des profiles fonctionnels justifiant un tel découpage (ce qui est incompatible avec une gestion fine des droits).