Discussion :

[escartefigue]

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.

[Nb]

Un article interessant même si le ton est tout à fait problématique.

Je pense que c'était ce que voulait dire Frédéric en mentionnant ces failles : les condamnations CNIL auraient pu être évitées simplement en utilisant de bons outils dès le départ.

Ou en embauchant des devs qui ne font pas n'importe quoi. Créer un repertoire pour accueillir des données en le laissant accessible...les dev et les personnes qui les recrutent et les laissent faire devraient peut etre penser à changer de métier en fait.
Mais c'est un autre probleme qui ne résoud en rien les difficutés qu'il y a pour réussir à garder cohérent un ensemble "DB+rep contenant des documents"

[sergio_is_back]

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...

[sergio_is_back]

Moi j'utilise sqlite, aucun problème

C'est pratique pour de l'embarqué mais SQLlite dans un environnement concurrentiel c'est pas possible...

Tu peux toujours utiliser un tournevis comme un marteau... mais bon...

[sergio_is_back]

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 ...

L’auto-incrément c'est juste pour générer un numéro d'enregistrement UNIQUE rien n'oblige à ce que ce dernier soit dans une suite logique il suffit juste qu'il soit unique... on pourrait tout aussi bien imager une numérotation random suffit juste de ne pas retomber deux fois sur le même numéro... C'est valable dans tous les SGDB... Et on n'utilisera surtout pas cela pour des numéro de facture !

[François DORIN]

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à...

Developpeur != DBA

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...

Sauf que l'exemple donné est tout à fait pertinent. La législation française par exemple impose une numérotation des factures continues. Si c'est effectivement à éviter, dans certaines situations, on n'a pas le choix.

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...

Je ne réagirais même pas sur les "prétendus lacunes" de SQLPro (ça n'a pas d'intérêt, et sa réputation répond pour lui ).
Je n'ai pas testé récemment MySQL sous Windows donc les choses ont peut être changées, mais le répertoire des données, à une époque tout du moins, était accessible directement en lecture/écriture à tout utilisateur ayant le role administrateur et en lecture aux autres.

Avec SQLServer, allez sur le répertoire de données et vous n'aurez aucun droits par défaut. Si vous êtes admin, vous pouvez vous les donner, mais c'est une autre histoire.

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

Non, il faut être admin en plus.

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 !

Pour le coup, c'est à vous de consulter la norme SQL. La division est entière car les nombres sont des entiers. Le bon résultat est donc... 1 !

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

div est propre à MySQL et n'est pas dans la norme

Je pourrais continuer longtemps comme ça...

Effectivement, on peut continuer longtemps comme ça, car l'article est à charge. Mais qui le soit ou non ne change rien à la véracité des faits évoqués. MySQL ne respecte pas le standard SQL et n'est pas prêt de le faire, à moins de casser la compatibilité avec l'existant.

[mongui]

Bonjour,
cet article est très interessant et permet d'attirer l'attention sur des negligences des utilisateurs, ainsi que sur des faiblesses de Mysql
Cependant, il me semble que sqlpro fait preuve d'un peu de mauvaise foi ou de beaucoup d'incompétence concernant MySql. Il aurait pu demander l'avis d'un expert MySql, ou montrer une certaine neutralité.

Sur la partie de l'article qui prétend qu'une instruction de ddl valide toute transaction, je n'ai pas compris pourquoi dans l'exemple aucun niveau d'isolation de transaction n'est précisé. Or, la gestion des transactions dépend du niveau d'isolation, et Mysql par défaut est au niveau read uncommitted. J'ai testé son exemple avec le niveau repeatable read et je n'ai pas eu de commit automatique avec une instruction de ddl, sur les autres transactions (j'utilise mysql8).
Pour moi, cela semble relever d'un peu de mauvaise Foi pour un expert en bases de données de parler de transactions sans mentionner l'impact des niveaux d'isolation, et de tester les transactions sans les définir.

Condamner le strict mode de Mysql relève simplement d'un manque de recul. Comment assurer la compatibilité ascendante avec les programmes si à un moment tout était permis et que plus tard on améliore en permettant que certaines choses deviennent interdites? La solution la plus simple est l'introduction d'un strict mode, pour ne pas faire planter les systèmes en production qui ne l'avaient pas respecté, et qui se limitaient à prendre les parties justes de la requête (autrement les utilisateurs se seraient plaints de bugs et il y aurait eu des corrections). Par contre, il est effectivement important d'attirer l'attention des developpeurs mysql sur la nécessité de définir ce mode de fonctionnement pour leur SGBD

avec mysql8, la collation par défaut est utf8mb4 et non latin1.
D'autres ont déja répondu sur d'autres points, sur lesquels je ne reviens pas.
Il aurait été souhaitable pour un tel article de préciser quelle version de MySql a été utilisée.

[Pyramidev]

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....

Sauf que l'exemple donné est tout à fait pertinent. La législation française par exemple impose une numérotation des factures continues. Si c'est effectivement à éviter, dans certaines situations, on n'a pas le choix.

Dans l'article, je ne sais pas si SQLpro a considéré le numéro de facture comme une clef primaire. Un peu plus loin, il y a un exemple avec une clef primaire de facture FAC_ID, mais je ne sais pas s'il la considère comme le numéro de facture.

Je ne suis pas DBA mais, à ma connaissance, l'une des bonnes pratiques des conceptions des bases de données est de ne jamais utiliser de donnée métier comme clef primaire.

En 2011, tchize_ a écrit un témoignage intéressant dans lequel une entreprise utilisait vraisemblablement le numéro de registre national comme clef primaire pour identifier des employés qui travaillaient en Belgique. Mais, pour les employés qui venaient de l'étranger, l'administration leur attribuait un faux numéro temporaire avant de leur attribuer le vrai, ce qui posait problème.

Je ne connais pas la législation française sur les numéros de facture, donc je ne sais pas s'il existe des cas tordus dans le même genre. Mais, comme on ne sait pas comment la législation va évoluer et qu'on n'a pas le contrôle dessus, alors choisir ces numéros comme clefs primaires me semble être une mauvaise idée.

[rawsrc]

l'une des bonnes pratiques des conceptions des bases de données est de ne jamais utiliser de donnée métier comme clef primaire.

+1000

On m'a toujours dit : colle autant d'index que tu veux sur des données métier mais ces dernières ne doivent JAMAIS avoir un quelconque sens informatique au niveau du moteur de base données, en conséquence tu dois laisser INTEGRALEMENT la gestion des clés et des relations basées sur ces dernières au moteur de base de données.
Donc tu es gentil et tu m'ajoutes des id auto-incrémentés à toutes tes tables.

Je dois avouer que cela m'a sauvé la vie plusieurs fois

[François DORIN]

Je ne suis pas DBA mais, à ma connaissance, l'une des bonnes pratiques des conceptions des bases de données est de ne jamais utiliser de donnée métier comme clef primaire.

Tout à fait. Mais ça, c'est dans un monde de bisounours où tout le monde est compétent ! Dans la réalité, quand on se base sur de l'existant, ben faut faire avec !

[DarkCenobyte]

Tout à fait. Mais ça, c'est dans un monde de bisounours où tout le monde est compétent ! Dans la réalité, quand on se base sur de l'existant, ben faut faire avec !

Après, il reste toujours possible d'entamer une migration pour corriger ces anomalies... Il est parfois même possible de jouer cela sans downtime... (fait hier, j'ai remplacé une table par une autre dans une migration durant environ 5h... Je ne dit pas que c'est toujours possibles, mais MySQL est loin d'être la pire horreur quand il s'agit de trouver des solutions pour réparer le passé... La plus grosse difficulté est plus souvent humaine si il s'agit de convaincre qu'il est nécessaire de passer du temps sur ça...)

Ensuite, comme dit dans d'autres messages, il y a différent comportement selon le réglage du niveau d'isolation d'une requête, et aussi selon le moteur utilisé (InnoDB-like, MyISAM, MEMORY, ...).

Et comme dit à plusieurs endroit, il ne faut jamais utilisé un id servant aux relations de tables, comme une donnée métier... Et ce n'est pas compliqué de rajouter une colonnes qui prendrait comme valeur la même chose que l'id pour le passé, mais en deviendrait indépendante par la suite en évoluant différemment.

Pour moi la primary key est synonyme d'unicité (et potentiellement d'optimisation vis à vis des indexs) et non de valeur métier, c'est généralement l'ID auto_increment, parfois (et dans tout les cas de tables partitionnés) une clé composite (dont la dernière colonnes est l'ID auto_increment encore, histoire de tirer sur le comportement des index B+TREE de InnoDB qui inclut nécessairement la PRIMARY en fin au maximum) (et de toute façon, si on en met pas, MySQL créera un id auto_increment interne aussi...)


Le sujet est juste un peu trop orienté dans le ton (et pour SQL Server... J'ai envie de dire, forcément si on est sur un Windows Server, Microsoft va pas avoir fait à la va-vite un outil dédié à son écosystème... D'où les jeux d'autorisations peut-être plus safe par défaut...), maintenant quand on vient du monde UNIX, on dira que tout est fichier, et que si root veux flingué sa machine, c'est son problème. A partir de là, c'est du bon sens de pas aller jouer avec des fichiers dont on ne maitrise pas le comportement, et qui ne sont pas fait pour ça.

[sergio_is_back]

Developpeur != DBA

Quand on est dans une PME on est tout à la fois

De manière générale dans les grosses structures les développeurs ne parlent pas au DBA qui ne parle pas aux admins serveurs qui eux ne parlent pas à l'administrateur réseau qui ne parle pas aux analystes, qui eux même ne parlent de toutes façons pas aux développeurs... Bref c'est souvent la famille PSG... C'est là que les problèmes arrivent...

Sauf que l'exemple donné est tout à fait pertinent. La législation française par exemple impose une numérotation des factures continues. Si c'est effectivement à éviter, dans certaines situations, on n'a pas le choix.

Non l'exemple ne l'est pas !
Comme le dit Pyramidev on n'utilise pas une donnée métier comme une clé
Après il y a toujours le problème de l'existant...

Je ne réagirais même pas sur les "prétendus lacunes" de SQLPro (ça n'a pas d'intérêt, et sa réputation répond pour lui ).

Publier un tel article n'est pas forcement de nature à renforcer sa réputation, justement ! A part voir le "PRO" MSSQL on ne voit rien d'autre...
Mais cet avis n'engage que moi évidement

Je n'ai pas testé récemment MySQL sous Windows donc les choses ont peut être changées, mais le répertoire des données, à une époque tout du moins, était accessible directement en lecture/écriture à tout utilisateur ayant le role administrateur et en lecture aux autres.


Avec SQLServer, allez sur le répertoire de données et vous n'aurez aucun droits par défaut. Si vous êtes admin, vous pouvez vous les donner, mais c'est une autre histoire.

J'ai répondu à ceci
On est jamais obliger d'utiliser la configuration par défaut...
On peut très bien lancer le service MySQL avec un compte et des droits spécifiques et restreindre les accès à ce compte sur le répertoire de stockage des fichiers MySQL
Du coup on obtient la même chose qu'avec MSSQL
Suffit juste de consulter la documentation...

La plupart du temps, je suis ADMIN sur les serveurs que je déploie... Du coup...

Pour le coup, c'est à vous de consulter la norme SQL. La division est entière car les nombres sont des entiers. Le bon résultat est donc... 1 !

Aucun SGBD ne respecte exactement la norme à la virgule et au point près, je suis payé pour le savoir... Ou alors il faut rester dans du SQL utra-basique (SELECT, INSERT, UPDATE, DELETE sans fioriture)

div est propre à MySQL et n'est pas dans la norme

Oui c'est vrai
Mais quand je travaille sur projet avec MySQL je travaille à partir de la documentation MySQL, quand je fais du MSSQL c'est avec la documentation MSSQL
Et devine quoi, le dernier projet que mené avec Oracle je me suis documenté où ? Sur le site d'Oracle !

Après je développe aussi en Pascal donc le "div" ne me choque pas, sans doute une déformation....

Effectivement, on peut continuer longtemps comme ça, car l'article est à charge. Mais qui le soit ou non ne change rien à la véracité des faits évoqués. MySQL ne respecte pas le standard SQL et n'est pas prêt de le faire, à moins de casser la compatibilité avec l'existant.

J'ai déjà répondu... (au dessus)

Si l'on en devait QUE respecter la norme SQL strictement on perdrai le bénéfice d'un tas de fonctionnalités sur beaucoup de SGBD... A part vouloir faire un code SQL portable d'une base à une autre (ça peut exister) je n'en vois pas l'intérêt...

[escartefigue]

On m'a toujours dit : colle autant d'index que tu veux sur des données métier mais ces dernières ne doivent JAMAIS avoir un quelconque sens informatique au niveau du moteur de base données, en conséquence tu dois laisser INTEGRALEMENT la gestion des clés et des relations basées sur ces dernières au moteur de base de données.
Donc tu es gentil et tu m'ajoutes des id auto-incrémentés à toutes tes tables.

Comme le dit Pyramidev on n'utilise pas une donnée métier comme une clé

Il faut arrêter l'hémorragie là, tout le monde copie/colle des énormités et ça ne choque personne !
Ce qui ne doit jamais être fait, c'est d'utiliser une donnée fonctionnelle comme identifiant primaire :
- la raison principale est que les identifiants fonctionnels sont instables, un nom, un siren, un numéro de téléphone, ça peut changer. Or modifier une clef primaire modifie également toutes les FK liées via les contraintes d'intégrité, ce qui peut provoquer des mises à jour en cascades pléthoriques et mettre par terre la base de données
- la raison secondaire est que les identifiants fonctionnels sont peu propices aux performances, ils sont plus encombrants que de l'integer et en général sensibles à la collation car de type (var)char.
Mais rien n'interdit, bien sur et bien au contraire, d'utiliser les identifiants fonctionnels comme identifiants alternatifs, uniques ou non, mais non primaires. C'est même très fortement recommandé, sans quoi, une recherche de tous les dupont dans la table des personnes risque de prendre un temps certain !

[Manu0086]

Comme beaucoup, article à charge pour prêcher pour sa paroisse... avant même la lecture, on sait déjà l'orientation que cela va prendre.

Je ne remets pas en cause les soucis possibles avec Mysql/MariaDB, mais ils répondent parfaitement à beaucoup de besoins.

Le soucis principal, c'est que les solutions dites "pro" coûtent très chères (et ont toujours coûté très cher), qu'elles nécessitent un poste supplémentaire à elles seules (DBA), alors qu'aujourd'hui la data est majoritairement gérée par de "simples" développeurs (autrefois, c'était les administrateurs réseaux qui s'en occupaient).
Il n'y a pas si longtemps (20 ans), les "DBA low-cost" utilisaient encore massivement Access... (que de souvenirs... pas que des bons lol) Puis le web a évolué, les besoins aussi... Mysql répondait parfaitement à de nombreux besoins. Il n'a cessé d'évoluer depuis.
Que des "grosses" entreprises l'utilisent aujourd'hui, ce n'est pas la faute de Mysql, et non, on ne peut pas dire que toutes les entreprises qui l'emploient font une erreur, loin de là. Mysql et le monde pro, ce n'est pas incompatible!

[walfrat]

Bien que je sois d'accord que MySQL c'est pas fait pour la production de base de données conséquente, on peut dire la même de SQLite.

Et je parie qu'en fait ... on le sait déjà tous ici. On pourrait aussi ajouté HSQLDB à la liste.

Ce qui est très amusant c'est que personnellement j'ai entendu une raison principale qui fait que MySQL était la bête noire en termes de performances qui n'est pas évoqué : le moteur d'optimisation des requêtes et le calcul des jointures (hashjoin, qui peut être est intégré aujourd'hui mais l'a pas été pendant longggtemps).

En outre je n'ai jamais vu ou entendu quelqu'un vanté que MySQL pouvait gérer des centaines de Go. J'ai connu un admin système certifié PostgreSQL qui disait bien qu'un MySQL bien configure pouvait largement faire le boulot pour des applications modestes qui n'était pas trop exigentes en perfs ou haute disponibilité. C'est tout ce que j'ai toujours entendu à son sujet, pas plus pas moins.

Et je suis parfaitement d'accord : MySQL est une base de données accessibles et suffisamment fiable pour des BDD de tailles modestes qui peuvent se permettre des interruptions de services pour une maintenance ou même pour un backup de nuit.

Le problème c'est que tout ceux qui l'utilisent ne sont pas au courant, et quand ils commencent à vouloir faire plus gros, ou que le projet à exploser son périmètre et volume de données prévu initial par plus d'une dizaine de fois, les ennuis commencent.

En plus certaines faiblesses de MySQL sont documentés ici mais au final, quand on les connait elles ne sont pas si gênantes

• la division par 0 qui renvoi null, c'est très bof mais bon ça peut se gérer.
• En tant que Javaiste : on en parle d'Oracle qui supporte toujours pas les auto_incrément et oblige donc une applis qui se veut un minimum générique à forcer l'usage de séquence direct (oui car par exemple dans PostgreSQL un auto incrément génère en fait un vrai objet séquence mais qu'on ne gère pas du coup) ?
• Le cryptage, ou hashage plutôt, peut être gérer côté applicatif sans problème.

En bref, cet article donne un avis sur lequel quiconque c'est renseigné sur le sujet est d'accord mais n'avance pas nécessairement les bons arguments à mes yeux puisqu'il semble déjà partir du fait que MySQL prétant pouvoir gérer d’aussi gros volumes de données que Postgres ou Oracle.

[al1_24]

on en parle d'Oracle qui supporte toujours pas les auto_incrément et oblige donc une applis qui se veut un minimum générique à forcer l'usage de séquence direct (oui car par exemple dans PostgreSQL un auto incrément génère en fait un vrai objet séquence mais qu'on ne gère pas du coup) ?

Il faut se tenir à la page...
L'auto-incrément est pris en charge par Oracle depuis la version 12c (2013), certes bien en retard sur la norme SQL-2003.

[Greg221]

Par rapport au chiffrement TDE, MariaDB intègre en natif la possibilité d'héberger ses clés sur AWS, ce qui permet d'avoir une certaine conformité (renouvellement, module HSM, etc.).
MySQL intègre aussi des solutions de Keyring mais la grosse différence se situe ce qui peut être chiffré (cf summary de la page https://www.percona.com/blog/2018/08...ver-for-mysql/).

[tanaka59]

Dans les truc farfelus on peut aussi trouver a redire sur :

* le top vs limit entre Access et SQL classique
* le caractère bonus en SQL qui est % et * en Access
* le group concat de MYSQL , traduit par du "pivot " en Access ... que dire du SQL du SAS Guide Enterprise qui oblige à faire du une "proc transpose" ?
* My SQL se fou de savoir que l'on a du texte ou numérique sur d'autre SGBD votre requête ne compile pas
* une joyeusté aussi quand on est en SAS pour la gestion date c'est des calculs alambiqués avec du + 21961 et x 86400 (car la calendirer démarre en 1960 et non pas en 1900 ... )
* on reparle aussi du fait de mettre un # dans du vieux code SQL oracle VS join qui n'est pas pris en seul dans tous les SGBD ?

[SQLpro]

J'aurai quand même toujours plus confiance en un logiciel libre qu'en n'importe quelle boîte noire propriétaire. Je peux maintenir le code et je sais ce qu'il s'y passe.

C'est simplement indispensable. A partir de là, les SGDB proprios sont nécessairement mauvais et dangereux selon moi, peu importe leurs qualités intrinsèques.

Une entreprise qui vend un produit a une responsabilité légale et obligatoire (défaut de conformité, défaut de vice caché… etc) que n'a pas le monde du libre. Autrement dit, tu peut te retourner contre Oracle, MS ou IBM pour leur imposer de corriger, alors que dans le monde libre c'est juste impossible !
C'est pour cela que certains états d'Europe, autrefois fervent défenseurs du libre, ont désormais imposé des logiciels propriétaires notamment pour tout ce qui est données à caractère personnelles ou sensibles...

A +

[bloginfo]

C'est tout de même osé d'affirmer comme vous le faites que MySQL et MariaDB ne seraient ni relationnels ni transactionnels, alors qu'ils s'appuient sur la motorisation InnoDB.

Votre démonstration est entachée de nombreuses approximations.

Bien à vous.


Denis Szalkowski, DBA

NB Je forme, j'audite, je fais des prestations sur MySQL depuis 2001 et sur MariaDB depuis 2009.