Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Découvrez les dangers de MySQL et MariaDB

Par Frédéric BROUARD (SQLpro)

Le 19 juillet 2019 à 02:37, par SQLpro

156 commentaires

18PARTAGES

Chers membres du club,

J'ai le plaisir de vous présenter cet article :

Découvrez les dangers de MySQL et MariaDB

Cet article a donc pour but de vous démontrer que MySQL/MariaDB n’est pas compatible avec la sûreté, la qualité et les performances attendues par l’entreprise. Il en est même dangereux ! Lire la suite de l'article...

Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre les bases de données MySQL.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

156 commentaires

Signaler un problème

miaou_

Membre du Club

Le 19/07/2019 à 9:16

Bonjour,
article intéressant mais très (trop) à charge.
Le principal reproche que je ferais à votre article concerne la forme : le ton employé assez sarcastique donne moins de poids à vos arguments (c'est mon avis).
Je comprends bien que ce ton est en adéquation avec votre fonction (expertise et audit de base de données), mais pour moi, cela ne le fait pas...
Certains chapitres semblent vouloir effrayer le lecteur:

celui listant les amendes dans les stockages de documents électroniques, alors que les failles relevées n'ont pour moi que très peu de rapport avec des fonctionnalités pures de sgbd. Il est plutôt rare (à ma connaissance) de laisser la gestion des documents électroniques au sgbd, cela est effectué par des systèmes informatiques dédiés possédant de nombreuses autres fonctionnalités dans ce domaine.
celui sur le chiffrement est hors sujet depuis MariaDB 10.1[.4] (voir ici). Je ne sais pas si cela répond totalement à vos attentes, mais donne néanmoins une autre vision de MariaDB.

Ensuite, n'étant pas expert en base de données, simple utilisateur depuis 20 ans de certains gros systèmes (Oracle, DB2 principalement), vous laissez penser que les solutions propriétaires sont le graal (notamment SQLServer qui revient souvent dans votre article). J'en doute fortement par mon expérience.
En plus d'être (très) coûteuses, ces solutions sont opaques. Vous semblez être expert en SQLServer notamment, sachez que côté Oracle, les opérations de support et maintenance sont très compliquées... sauf à payer le prix fort en abonnement adéquat (et encore, les bugs remontés ne sont jamais remontés dans un hotfix).

MySQL/MariaDB ont en effet de grosses lacunes, sur les points que vous évoquez (même si certains restent anecdotiques de mon point de vue),
mais il s'agit d'un moteur sgbd (ou de 2 ^^) possédant sûrement quelques qualités que vous ne citez pas (je ne le ferai pas moi-même, n'étant pas expert dans le domaine). Et sa gratuité et son aspect open-source sont un plus pour beaucoup, même dans le milieu de l'entreprise.

Je tiens quand même à vous remercier pour cet article, certains points m'étaient méconnus,
et puis, tout est question de nuances ;-)

Bonne journée,
Nicolas

FatAgnus

Membre chevronné

Le 22/07/2019 à 23:10

Le nom n’a d’ailleurs pas été choisi au hasard. MySQL ne signifie-t-il pas que c’est « mon petit business », loin des nécessités professionnelles d’une entreprise ?

Le nom « MySQL » vient du prénom de la fille du cocréateur Michael Widenius, sa fille se prénomme « My ». Ce début illustre bien l'état de l'esprit de l'auteur rempli de préjugés et prêt à enfoncer MySQL à chaque occasion. Le benchmark date de 2014 et mesure MySQL 5.6. En cherchant un peu Michael Widenius aurait pu trouver des benchmarks de MySQL 4.0.

Article qui aurait pu être intéressant s'il avait été impartial, mais bon venant d'un MVP Microsoft qui écrit des livres sur SQL Server pouvait-on en espérer autre chose ?

FatAgnus

Membre chevronné

Le 25/07/2019 à 10:24

Envoyé par webMCA

SQLPro, des excuses, peut-être, concernant cette erreur dans votre article concernant l'origine du nom "mySQL" ?
A tout le moins un "ERRATA" ?

Je ne pense pas qu'il faut s'attendre à des excuses ou des corrections de la part Frédéric Brouard, cet article s'inscrit dans la ligné des articles Fear, uncertainty and doubt publiés il y a quelques années par Microsoft contre Linux.

Je ne suis pas un expert SQL ni en FUD comme Frédéric Brouard, mais à mon humble niveau j'ai relevé quelques tromperies :

Tromperie sur le nom de MySQL : MySQL s’appellerait MySQL car il ne serait pas un produit professionnel alors que le nom vient du prénom de la fille du cocréateur de MySQL Michael Widenius. Dans tout l’article MySQL est qualifié de produit non professionnel et comme un outil de bidouilleur. Alors que MySQL est développé par Oracle depuis dix ans. MySQL est bien développé par des professionnels, des développeurs d'Oracle payés pour, et utilisé par des professionnels. D'ailleurs Frédéric Brouard avoue avoir un ou des clients qui utilisent MySQL.

Tromperie sur les benchmarks : des benchmarks mesurant les performance de MySQL 5.6 sorti en février 2013, voilà plus de six ans, alors que MySQL 5.7 et 8.0 sortis depuis sont données comme plus performants. Il faudrait rappeler à l'auteur que nous sommes en 2019 et des des benchmarks d'un logiciel de 2013 n'ont que peu d'intérêt.

Références sur des sanctions sans rapports avec MySQL. Des références à des amandes à des sociétés ne respectant pas le RGPD ou pour ne pas avoir respecté les données des utilisateurs, dans le seul but d'attiser la peur de MySQL, alors que rien de dit que ces sociétés utilisaient MySQL (peut-être ces sociétés utilisaient-elles SQL Server ou des fichiers textes bruts, rien ne le dit).

Tromperie sur la taille du code. Confusion de la taille d'installation avec la taille du code. Puisque MySQL occupe 210 Mo et SQL Server et 7 720 Mo, donc SQL Server contiendrait 37 fois plus de code. Conclusion plus que douteuse, puisque rien ne prouve que les fichiers installés dans le cas de SQL Server soient tous des binaires, et il me semble, sauf erreur de ma part, que SQL Server fournit aussi certains autres programmes avec une interface graphique. Enfin les binaires générés dépendent aussi du compilateur. Microsoft ne communique pas me semble-t-il sur la taille du code de SQL Server.

Tromperie sur les bugs : MySQL est un projet open source, donc la liste des bugs est ouverte. Microsoft ne communique pas sa liste de bugs il me semble, alors comment comparer ? Le site feedback.azure.com (comme le nom « feedback » l'indique) est destiné aux utilisateurs, pas aux développeurs de SQL Server.

Tromperie sur les bugs : MYSQL, MySQL comporte 73 738 bugs (d'où l'auteur tient-t-il ce chiffre ?) donc c'est un outil de bidouilleurs. L'auteur oublie que tous les projets open source, de fait de leurs natures open source, ont une toujours de grandes listes de bugs. Exemple le projet Chromium comporte 61 801 bugs , Chromium est donc un projet de bidouilleurs sur lequel Microsoft va baser son navigateur web Edge qui, si on suit le raisonnement de l'auteur, exposera les utilisateurs de Windows à des malfaçons. Je n'ai pas recherché le nombre de bugs ouverts dans le noyau Linux ou Mozilla Firefox, mais je pense qu'on doit atteindre des chiffres similaires.

Tromperie sur les bugs : 73 738 bugs laissent à penser qu’un très grand nombre d’utilisateurs ont été victimes des malfaçons. L'auteur essaie de tromper le lecteur en faisant un parallèle douteux entre le nombre de bugs et les failles de sécurités. Un bug n'est pas forcément une faille qui pourrait être utilisée comme une malfaçon.

Tromperie sur les CVE : l'informatique pour l'auteur s'est arrêté en 2016, benchmark de 2016 d'un logiciel de 2013 et des CVE de 2010 à 2016. Pour rappel nous sommes mi-2019 et l'informatique est un domaine qui évolue très vite. Puisque MySQL possède 35 fois plus de CVE que SQL Server sur la période entre 2010 et 2016, MySQL serait 35 fois pire que SQL Server en 2019. L'auteur oublie aussi qu'il faut tenir compte du niveau des failles, évaluées de zéro à dix ainsi que le temps de correction de ces failles.

Enfin pourquoi la faille dans la conception de MySQL permet à des serveurs malveillants de voler des fichiers à des clients, si c'est une faille ne fait-elle pas l'objet d'un CVE ? Si c'était le cas un CVE existerait, où est ce CVE ?

On notera aussi la confusion entre le libre et l'open source, l'auteur ne semble pas faire la différence. MariaDB et MySQL sont des projets open source. Je ne pense pas que l'objectif d'Oracle en développant MySQL soit que les utilisateurs puissent profiter des libertés du logiciel libre.

Enfin l’article dénigre aussi le logiciel libre et open source (qu'il confond). Certaines technologies seraient hors de portée du monde libre. Comme si la licence d'un logiciel ait quelque chose à voir avec son implémentation et sa qualité. Une manière détournée d'enfoncer encore plus MySQL, qui puisque MySQL est open source, il n'arrivera jamais à la cheville de SQL Server le Saint-Graal des bases de données.

L'auteur semble bien connu pour s'être donné comme mission de faire de la propagande SQL Server au détriment des base de données open source, et il fait ça depuis très longtemps. J'ignore pourquoi l'auteur s'est donnée cette mission, il ne serait pas surprenant qu'il en tire quelques avantages en coulisses.

escartefigue

Modérateur

Le 19/07/2019 à 16:06

Envoyé par stephweb

C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
Je m'explique :
Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

Pour détourner ce "problème", pour résumé je fais ceci :
Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.

Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple

escartefigue

Modérateur

Le 20/07/2019 à 11:13

Envoyé par tanaka59

Bonjour,

Dans les truc farfelus de mysql j'ai trouvé ceci

:

Créez une table ou vous injectez automatiquement de la data. Votre clef est un autoincremente. L'autoincremente a une gestion désastreuse des numéros ... Vous insérez 10000 lignes , votre compteur passe de 5000 à 7000 sans raison vous arrivez donc à 12000 .

Vous pensez au final avoir 12000 , erreur ! Vous en avez bien 10000 ... Pourquoi un tel comportement ? L'autoincremente n'est pas au point.

C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...

Voilà un discours symptomatique de la méconnaissances du fonctionnement des identifiants attribués par les SGBD, l'auto-incrémenent n'est pas en cause.

La présence de trous est tout à fait normale et n'est pas spécifique à MySQL.

- les identifiants attribués par le moteur qui ne sont pas commités sont perdus
- la valeur initiale de l'identifiant est paramétrable, rien n'interdit de démarrer avec une valeur différente de zéro ou un
- le pas d'incrément est paramétrable (pour MySQL, c'est la variable AUTO_INCREMENT_INCREMENT qui pilote cet incrément, MySQL prévoit jusqu'à 65535 comme valeur d'incrément)
- certains SGBD permettent en outre de choisir au choix un incrément ou un décrément
- certains SGBD permettent également de revenir à la valeur initiale si. le compteur a atteint le max, (il faut bien sur en ce cas que les identifiants anciens aient été supprimés physiquement de la DB sinon il y aura plantage pour clef en double).
- pour éviter de solliciter le moteur de la BDD à chaque insert, certains SGBD réservent ces identifiants par plage (la taille de la plage étant paramétrable). Chaque thread ayant besoin d'un nouvel identifiant, en récupère un dans cette plage, mais, bien sur, il est possible que tel thread fasse son commit avant tel autre et enregistre ainsi un identifiant d'une valeur supérieure à celle de l'identifiant d'un autre thread qui n'a pas encore commité.

Ces deux derniers phénomènes justifient que les identifiants ne sont pas toujours chronologiques.

Gregslv

Membre à l'essai

Le 19/07/2019 à 10:16

Désolé, mais comme miaou_, je n'adhère pas du tout au discours.

L'exemple IV.A en est la parfaite illustration ... SQLServer n’empêchera absolument pas la suppression d'un fichier si le serveur est arrêté ! Le sujet chiffrement est traité tout autant à charge, cela donne l'idée du reste de l'article ! Enfin, laisser penser que MySQL est réalisé par un suédois dans son garage alors qu'il appartient depuis plus de 10 ans à Sun puis à Oracle ...

N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !

chrtophe

Responsable Systèmes

Le 19/07/2019 à 14:55

Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire dans premier temps côté code.

Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.

Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.

En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.

sergio_is_back

Expert confirmé

Le 20/07/2019 à 12:24

Ce qui aurait pu être un article intéressant (c'est toujours bien d'avoir conscience des forces et des faiblesses de tel ou tel système que l'on utilise) c'est transformé en pamphlet déjà rien que le titre...

MySQL et MariaDB ne sont pas pires que leurs concurrent commerciaux. Après plus de 30 ans d'informatique j'ai assez donné pour le savoir. Oracle et MSSQL ont aussi leurs biais et que dire de DB2, OpenIngres, Gupta, Informix, Sybase, Interbase, Firebird and Co ? (J'ai un moment ou l'autre travaillé avec et même HyperFile, le client est roi on ne fait toujours le choix)

J'utilise MySQL depuis la version 4 et MariaDB depuis la version 10.0

Quelques perles :

Pour information, la collation(3) par défaut des serveurs et des bases de données dans MySQL est « latin1_swedish_ci » ! Beaucoup de développeurs n'ont pas remarqué cela et laissent en production cette collation qui peut s'avérer une bombe à retardement en matière de gestion des données accentuées, car le jeu de caractères accentués de la langue suédoise n'est pas compatible avec les principaux accents du français.

Quand on est pas capable de choisir la bonne collation, le bon jeu de caractères, à la création d'une base ou d'une table, on reste chez soi... Et on ne se prétend pas "Développeur" déjà...

Après ça ne pose que très, très peu de problème avec les caractères accentués français, j'en ai déjà fait l'expérience... Surtout que j'évite de mettre des colonnes avec du texte dans mes clés et mes index... Un export en UTF8, mise à jour de la table avec la bonne collation et ré-import des données aura tout fait de régler le problème...

Imaginez le jour où vous aurez besoin de rectifier des numéros de facture, parce que le système informatique étant tombé en panne, on a édité des factures à la main.

C'est de toute façon une TRES MAUVAISE HABITUDE d'updater les clés dans n'importe quel SGBD...

Imaginez avec des contraintes de clés étrangères dans d'autres tables....

Vous n'êtes pas aussi "PRO" que ça finalement...

Allez maintenant dans le répertoire de stockage de votre base, par exemple, par défaut, pour MariaDB sous Windows c’est : C:\Program Files\MariaDB 10.3\data.

Vous y trouverez les répertoires des bases, sachant que pour MariaDB/MySQL, une base c’est avant tout un répertoire.

Perso je n'utilise pas ce paramétrage pour la simple raison que c'est un endroit sensible pour les anti-virus sous Windows en particulier Kapersky et BitDefender, ils ont tendance à considérer toute tentative d'écriture comme suspecte et ralentissent les écritures dans la base...
Il vaut mieux configurer MariaDB ou MySQL pour placer le répertoire dans un endroit plus neutre (C:\MySQL\data ou autre) et n'accorder les accès en écriture qu'au système et aux administrateurs....

Çà évitera du coup à un simple utilisateur de pouvoir faire ce que vous faites plus haut.... Ça montre encore vos lacunes...

Que ce soit n'importe quel SGBD la configuration par défaut n'est jamais optimale... Il faut toujours adapter celle-ci...

Dans certains SGBDR, les fichiers de la base sont tellement sécurisés, qu’il n’est même pas possible d’en déplacer le stockage, supprimer des tables ou copier les fichiers.

C’est le cas, en particulier, de Microsoft SQL Server où le système va interdire une telle manipulation.

Si j'arrête les services SQLServer, je peux craquer tous les fichiers que je veux...
A peine plus sécurisé donc....
Idem avec Oracle....

SELECT 3/2 doit donner 1. MySQL/MariaDB renvoie 1.5 !

Vous faites une division en virgule flottante et ça vous choque d'avoir 1.5 comme résultat ?
Consultez la documentation MySQL avant d'écrire des bourdes !

Utilisez SELECT 3 div 2 plutôt (comme en Pascal) pour une division entière....

Je pourrais continuer longtemps comme ça...

Un peu constructif :

Les avantages que je trouve à MariaDB

- Facilité d'installation
- Légèreté
- Empreinte mémoire et CPU raisonnable (y'a besoin pas de 16 cores, 32 Go de mémoire même avec des gros volumes)
- Très bonne réactivité (encore faut il que les clés, les index soient utilisés à bon escient)
- Supporte de très gros volumes sans broncher sans dégradation visible des performance (voir le point au dessus)
- Bonne compatibilité ascendante (c'est facile de passer de MySQL 5.x à MariaDB 10.x)

Les inconvénients :

- Depuis qu'Oracle a repris MySQL ce dernier ressemble de plus en plus à une usine à gaz
- Tous les outils d'admin sont en mode console (ça peut en rebuter certains comme le rédacteur de cet article)
- HeidiSQL fournit avec MariaDB est une bouse ça c'est sur (plantages réguliers, ça rame dès que l'on a des très grosses tables)
- C'est dommage que les MySQL GUI Tools n'évoluent plus ils étaient de qualité nettement supérieure à HeidiSQL

Pour ma part :

Avec de nombreuses installations en service, et quelques crash bien sur comme sur tout système, je n'ai jamais eu à constater la moindre perte de données que ce soit sous Windows ou Linux....

Après c'est comme tout : Lorsque l'on utilise les choses à bon escient et en respectant de bonnes pratiques (dans les règles de l'art) tout ce passe bien. Lorsque l'on utilise un logiciel pour autre chose que ce qu'il a été conçu à la base en essayant de lui tordre le bras... Et bin ça tourne à la catastrophe...

Xurudragon

Membre du Club

Le 19/07/2019 à 16:37

Envoyé par stephweb

Yes.
Mais beaucoup de dév utilisent les id pour les numérotations de factures.

Mais là ce n'est, encore une fois, pas un problème de SGBD, mais un problème de connaissance du/des développeurs

sfavreau

Futur Membre du Club

Le 25/07/2019 à 16:41

Bonjour,

MySQL est présenté comme un SGBDR relationnel et multitransactionnel cependant son implémentation est imparfaite et ne correspond pas exactement à la norme SQL. Les requêtes avec "group by" suffisent pour le prouver et la démonstration de SQLpro est suffisamment détaillé. Cependant cela a été un choix dès l'origine et en effet MySQL ne sera jamais un SGBR relationnel et multitransactionnel comme Microsoft et Oracle l'entendent avec SQL Server et Oracle Databases.
https://aws.amazon.com/fr/relational-database/
Dans le monde libre PostGreSQL respecte mieux le principe du SGBDR relationnel et multitransactionnel.
Une fois que cela est dit, est ce que cela dévalorise MySQL ? Surement pas ! MySQL a son intérêt et d'abord la simplicité de sa prise en main à contrario des 2 leaders. C'est quand même le SGBDR le plus répandu pour la gestion des sites internet. Facebook dont les développeurs sont surement des petits rigolos l'a utilisé pendant longtemps. Concernant le nom du logiciel, celui ci fait en effet référence au prénom de la fille de l'auteur et signifie littéralement "Mon SQL" (à moi) ce qui veut bien dire que cela correspond au SQL que voudrais utiliser le concepteur et non une référence à la norme. Je pense qu'il est préférable de commencer par MySQL puis si on s'intéresse aux SGBDR, on pourra évoluer vers SQL server / oracle.
Je souhaitais revenir sur :

Allez maintenant dans le répertoire de stockage de votre base, par exemple, par défaut, pour MariaDB sous Windows c’est : C:\Program Files\MariaDB 10.3\data.

Vous y trouverez les répertoires des bases, sachant que pour MariaDB/MySQL, une base c’est avant tout un répertoire.

C'est sur ce type d'argument que l'auteur perd sa crédibilité. En effet, il compare une installation Windows Server / SQL Server avec une installation de MySQL sur un environnement W7/W10 + WAMP ou easyphp. Là en effet, on pourra supprimer le contenu des bases mais il s'agit d'un environnement de test et surement pas de production. En règle général et en production avec les bonnes pratiques, MySQL est installé sous Linux et se trouve /var/lib/mysql et là, je suis désolé l'utilisateur sans droit ne pourra pas effacer les bases et supprimant le contenu du répertoire Un utilisateur root oui mais il faudra être root en sachant quand dans les bonnes pratiques il faut créer un utilisateur sans droit et lui donner les droits d'accès uniquement à une base donnée.
Sous windows server c'est un peu la même chose, si on est pas admin, on aura du mal à supprimer les .mdf et .ldf cependant l'élévation de privilèges est plus simple sous windows que sous Unix / linux.

Je suis de l'avis de FatAgnus, on a l'impression que l'auteur est encore sous l'ère Steve BALLMER qui considérait "Linux comme un cancer". Ce n'est plus le discours de Microsoft en 2019, visual studio code est sous linux, sql server lite est sous linux, W10 dispose d'un shell linux, Microsoft est contributeur Linux....

D'autre part, on ne parle pas de l'allocation mémoire de SQL Server, la semaine dernière un éditeur de logiciel m'a demandé de lui mettre à disposition un serveur à 32Go de RAM pour SQL Server. C'est simple désormais, pour remplir 1000 lignes / jour, un serveur SQL Server, c'est minimum 16Go ! Un serveur MySQL avec 4 Go aura des meilleures performances notamment en lecture.

Bref, pour ma part, je considère que MYSQL est un excellent produit cependant c'est vrai que pour des applications très critiques SQL Server sera plus adapté, cependant vu le prix de la licence SQLserver, il est préférable de l'utiliser uniquement quand on ne peut pas utiliser MySQL.

Identifiez-vous

Créer un compte

Découvrez les dangers de MySQL et MariaDB Par Frédéric BROUARD (SQLpro)

Découvrez les dangers de MySQL et MariaDB

Par Frédéric BROUARD (SQLpro)