Discussion :

[ericd69]

bon mon cher sqlpro, on avance...

tu nous la joues un peux comme beaucoup de politiques (trop nombreux à citer) qui, quand ils se font prendre à dire n'importe quoi, attaquent vite pour essayer de faire oublier leurs erreurs...

pas grave, on a corrigé la contre vérité sur les licences déjà

pour les commerciaux mysql, je suis pas convaincu... car comment tu expliques le nombre de projets open source qui s'imposent sans commerciaux et même face à eux?



là encore les causes sont plus complexes car dépendant des choix de virtualisation, de ressources allouées aux différents processus et utilisateurs liés à un hébergement... après niveau licences les hébergeurs ne payent pas plus que tout autres utilisateurs vu que leur utilisation rentre dans le cadre de la licence GPL... sinon ils seraient vite passé à postgreSQL en effet par exemple...

tu payes quand ils font payer pour le SGBD à la taille de BD et au prorata de leur nombre que tu as...

les licences commerciales sont liées au nombre de sockets par installation et franchement chères... y a qu'à aller voir sur la boutique en ligne d'oracle...

et le but des hébergeurs comme toute entreprises et de maximaliser leur gains...

et question virtualisation, quotas, etc... c'est bizarre comme les hébergeurs y arrive bien, non?

avec les réglages de base sous windows, le processus mysqld utilise (sans que rien ne soit requêter) 28.6M d'image mémoire avec 16 bd installées sur mon ordinateur, faudrait voir sous linux et ensuite une configuration de base pour un mutualisé et pouvoir comparer dans ces différents cas...

ça serait intéressant de rassembler des infos là dessus pour voir comment ça évolue en fonction du nombre de bd, etc... si certains veulent donner cette tailles avec le nombre de bd pour voir son influence... ça pourrait être intéressant et sur tout concret peut-être...

ensuite les réglages possibles sont plus ou moins les mêmes pour tous les SGBD... donc là aussi, faut un peu arrêter de faire du prosélytisme sans vrais arguments...

après ce serait aux hébergeurs de répondre non?

donc oui mysql a plein de défauts mais il permet de faire beaucoup de choses très poussées quand même pour peu qu'on sache vraiment l'utiliser (ou qu'on en prenne le temps)...

bonne lecture

[CinePhil]

donc oui mysql a plein de défauts mais il permet de faire beaucoup de choses très poussées quand même pour peu qu'on sache vraiment l'utiliser (ou qu'on en prenne le temps)...

Il permet surtout une installation et une utilisation plus facile que les autres SGBD (je ne connais que Postgresql et Oracle cependant), notamment avec phpMyAdmin mais pour faire des choses poussées il vaut quand même mieux se tourner vers un autre SGBD car les lacunes de MySQL sont pénalisantes très tôt dans l'échelle de complexité. Pour n'en citer que 2 pourtant assez élémentaires mais qui nécessitent du développement spécifique chez MySQL :
- l'absence de contrainte CHECK ;
- l'absence de gestion d'erreur dans les triggers.

Et ce qui est piégeux pour le premier des deux, comme pour les clés étrangères avec le moteur MyISAM, c'est que MySQL accepte les instructions sans broncher mais les ignore totalement sans avertir l'utilisateur qui peut ainsi se croire à tord protégé par les contraintes qu'il a programmées. Il n'y a qu'à voir le nombre de messages du genre "Ça marche pas je ne comprends pas pourquoi" reçus dans le forum MySQL pour se rendre compte que le programmeur pas trop au fait des lacunes de MySQL peut se faire piéger très rapidement et très facilement par ce SGBD.

[ericd69]

là on est tout à fait d'accord...

sans compter quelle que limitation dans les collations et l'implémentation de l'utf8 qui peuvent surprendre aussi...

tiens dis moi qu'elle taille d'image mémoire tu as pour le processus de postgresql ?

[tse_jc]

Bonjour,

Le succès de MySQL il faut bien le dire aussi quelque part, tient du fait que les prérequis de compétences et de qualification sont largement moindres que chez SQL Server ou dans une moindre mesure postGreSQL pour le faire tourner dans de bonnes conditions.
Pour reprendre les propos de SQLpro, l'administration sur MySQL est quasi absente, et je rajouterai, dans le sens où elle n'est sans commune mesure avec celle d'un vrai SGBDR. Du coup la plupart du temps l'administration sur MySQL consiste à contrôler et surveiller ce que font les devs sur le serveur. Les besoins des PME-PMI, principaux utilisateurs de MySQL, ont des volumétries qui la plupart du temps ne nécessitent pas de réelles compétences pour les administrer, mêmes si la plupart iront dans le mur le jour où leur activité va considérablement croître, et que cela sera trop tard. Le choix massif d'utilisation de CMS n'en est que la triste preuve.

D'un point de vue adm, les problèmes évoqués de MySQL sont la plupart du temps plus ou moins "contournables" quand on connait son boulot, mais c'est vrai aussi que normalement en tant qu'adm on a autre chose à faire aussi de plus constructif et interessant...

[Seb33300]

MySQL est au même titre que PHP très (trop) souple.

Quand n'importe quel SGBD va te jetter si :

tu tentes de faire un select d'un champ dans une requête group by sans que ce champ soit dans le group by, MySQL ne dira rien.

tu tentes d'insérer un string de 30 caractères dans une varchar(20), mysql le tronquera sans rien dire


Je trouve que mysql est dans la lignée de PHP qui est lui aussi très permissif et c'est pour cela qu'il vont bien ensemble.
(Et c'est aussi pour ça qu'on l'aime ? )
Après c'est comme tout, il faut savoir ce que l'on fait quand on utilise ce genre d'outils.