8 pièges incontournables de MySQL

Mysql est facile à installer, rapide et riche en fonctionnalités. De plus, c'est également une référence pour le mouvement open source. Ses grandes réalisations nous montrent qu'une entreprise prospère peut être construite sur du code open source.

Cependant, tous ceux qui ont utilisé MySQL ont brandi le poing vers le moniteur. Mais vous ne pouvez pas inventer une technologie capable de sauvegarder des milliers de lignes de données Internet par seconde sans aucune erreur.

Pour vous enthousiasmer cet été, nous listons 8 raisons de se plaindre des bases de données relationnelles open source. Les raisons énumérées ci-dessous ne se limitent pas à MySQL, certaines sont spécifiques aux bases de données relationnelles. Si nous ne comprenons pas les bases de données relationnelles et MySQL, nous resterons toujours coincés dans la pensée des années 1990. Nous devons les démolir puis les reconstruire. Ou nous nous tournons vers une base de données récemment populaire qui n'existe pas depuis assez longtemps pour justifier un certain nombre de raisons comme celle ci-dessous.

Bogues profondément enracinés

Tout gros paquet contient des bogues. Mais si vous creusez un peu plus, vous constaterez que les bugs liés à Mysql sont autonomes. Soudainement, vous devez faire attention, car NULL n'apparaît pas de la même manière, les contraintes de clé étrangère ne fonctionnent pas comme vous le pensez et même l'auto-incrémentation de clé primaire se passe mal.

Les petits problèmes abondent et ne sont pas toujours réparables, c'est pourquoi certaines personnes tiennent une liste. Heureusement, MySQL maintient un très bon système de rapport de bogues, afin que nous puissions savoir des choses que nous ne pouvons pas imaginer et savoir que d'autres traversent la même épreuve.

La rigidité des tables relationnelles

Les tables relationnelles sont organisées et l'organisation est bonne - cependant, elle oblige les programmeurs à inventer ou à regrouper certaines données dans un schéma défini dans la colonne. L’une des raisons pour lesquelles NoSQL devient de plus en plus populaire est qu’il offre aux programmeurs suffisamment de flexibilité pour accélérer l’utilisation des bases de données. Si une adresse postale nécessite une ligne supplémentaire, vous pouvez facilement l'insérer dans un document NoSQL. Si vous souhaitez ajouter un nouveau bloc de données complet, quel que soit ce qu'il contient, le modèle de document peut également accepter vos données telles quelles sans avoir à les modifier au format de données requis.

Imaginez que vous créez un tableau avec tous les codes postaux au format entier. Cette table est très efficace et les règles qu'elle applique sont très bonnes. Soudain, quelqu’un a téléchargé un code postal à neuf chiffres utilisant des traits d’union. Ou peut-être recevez-vous une lettre d’un client au Canada avec un code postal dessus.

A cette époque, tout était dans le chaos. Le patron exige que le site Internet soit à nouveau opérationnel d’ici quelques heures. Cependant, nous n’avons pas le temps de reconstruire la base de données. Que peuvent faire les programmeurs ? Peut-être que des pirates informatiques pourraient être utilisés pour changer le code postal canadien du format numérique base64 au format base 10 ? Ou créer un tableau auxiliaire utilisant des codes d'échappement pour prendre en compte le vrai code postal ou autre chose ? Qui sait ? Il y a des hackers partout et ils sont dangereux. Mais vous n’avez pas le temps de le comprendre.

Les règles d'association de MySQL maintiennent tout le monde honnête et prudent, mais elles nous obligent à éviter d'être vulnérables et trompeurs.

JOIN requête conjointe

Il était une fois, la sauvegarde des données dans des tableaux séparés était une grande innovation dans l'histoire de l'informatique. La table séparée a non seulement une structure simple, mais simplifie également son utilisation. Mais cela nécessite l’utilisation d’une instruction join pour la requête.

SQL pousse les développeurs dans l'abîme de la confusion et du désespoir grâce à des requêtes complexes construites via une série de jointures. De plus, le moteur de stockage doit également analyser efficacement l’instruction de jointure de manière optimale. Les développeurs doivent se creuser la tête pour écrire des instructions de requête, puis la base de données les analyse.

C'est pourquoi de nombreux développeurs qui se concentrent sur la vitesse d'exécution abandonnent les sous-tableaux de données et utilisent à la place des tableaux de données non standard. Ne faites pas de différence entre les entités de données et enregistrez toutes les données dans une seule grande table - pour éviter les requêtes complexes. C'est très rapide et le serveur ne manque pas de mémoire.

L'espace disque est bon marché de nos jours. Des disques de 8 To sont déjà en vente et des disques plus gros arriveront bientôt. Nous n’avons plus besoin de nous creuser la tête pour utiliser join.

La confusion des branches

Oui, un fork MySQL solide et bien pris en charge peut apporter de la concurrence et du choix, mais il peut aussi semer la confusion et la confusion. Pour aggraver les choses, il existe un fork de MySQL appelé MariaDB, maintenu par Monty Widenius. Il est également impliqué dans l'écriture de MySQL. Alors, MariaDB est-elle vraiment indépendante et digne de notre soutien ? Ou est-ce MySQL ? Devons-nous nous en tenir au code de base exploité par l’organisation qui a créé la base de données MySQL d’origine ? Ou devrions-nous nous joindre aux transfuges souvent cool et considérés comme plus intelligents ?

De plus, comment obtenons-nous des informations sur la compatibilité ? D'une part, nous sommes convaincus que MariaDB et MySQL sont très similaires. D’un autre côté, il faut croire qu’il y a une différence – sinon pourquoi tout le monde en discute ? Peut-être fonctionnent-ils de la même manière dans les deux camps, en termes de performances et de portée de notre requête ? Mais peut-être qu’ils sont différents – ou qu’ils le seront à l’avenir.

Confusion du moteur de stockage

MySQL n'est pas de facto la même base de données ; il est composé de plusieurs bases de données, la plupart de leurs détails étant masqués par une surface uniforme. Au début, il existait un moteur MyISAM, rapide mais pas complet en termes de cohérence. Parfois, c'est une bonne chose lorsque vous avez besoin de rapidité et que vous pouvez accepter des résultats incohérents.

Lorsque les gens avaient besoin de plus, InnoDB est apparu avec un support complet des transactions. Mais cela ne suffit pas. Désormais, il peut proposer 20 choix de moteurs de stockage, de quoi rendre fou un administrateur de base de données. Bien sûr, il y a des moments où il est agréable de basculer entre différents moteurs de stockage sans avoir à réécrire votre code SQL, mais il y aura toujours du chaos après le changement. Dois-je choisir MyISAM ou innoDB comme moteur pour cette table ? Alternativement, les données que je décide de générer seront-elles au format CSV ?

Motif de profit

Bien que MySQL soit un produit open source à succès, il s'agit toujours d'une entreprise remplie de développeurs professionnels qui sont payés par celui-ci. Alors que la plupart des utilisateurs continuent de bénéficier de la meilleure expérience offerte par les licences open source, il ne fait aucun doute que cette société a encore du mal à gagner suffisamment d'argent pour maintenir ses opérations. Cela conduit à une étrange bifurcation du code libre entre les « éditions communautaires » et les produits complets vendus aux entreprises.

Devriez-vous payer ? Combien d'argent gagnez-vous ici ? Est-il juste de fonctionner sur une version communautaire ? Les fonctionnalités supplémentaires de la version entreprise ne sont-elles qu’un gadget pour nous inciter à payer plus ? Cela montre au moins qu’il s’agit d’une autre série de questions auxquelles il faut répondre. Quelle version choisir ? Sous quelle licence ? Quel ensemble de fonctionnalités dois-je utiliser ?

Manque de support JSON natif

La meilleure façon de connaître l'âge de MySQL est de l'installer, puis vous réalisez que vous devez ajouter plus de pilotes pour le rendre utilisable. MySQL communique généralement sur le port 3306 et génère généralement des données formatées qu'il ne peut pas comprendre. Si vous voulez que votre code communique avec lui, vous devez ajouter une autre couche de code qui traduit le langage de MySQL en quelque chose d'utile. Le code de ces couches est distribué sous forme de bibliothèque, ce qui oblige souvent les utilisateurs à acheter une licence commerciale.

Les couches de stockage de données modernes communiquent souvent directement en JSON. Bien que MySQL et MariaDB aient désormais la capacité d'analyser la partie JSON de SQL, cela est loin d'être suffisant et l'interface JSON native est déjà largement utilisée dans CouchDB, MongoDB ou tout autre outil récent.

L'essor des modules sources fermés et propriétaires

Ai-je mentionné que MySQL est open source ? C'est le cas, à l'exception de certains codes non open source plus récents et de modules propriétaires développés autour du "noyau open source". Les programmeurs ont besoin de manger et Oracle doit échanger le fruit de son travail acharné contre de l'argent. C'est l'une des réalités du monde des affaires. Ce n'est pas comme ces hôpitaux où vous bénéficiez de soins médicaux gratuits grâce à MySQL. Ce n'est pas comme ces agriculteurs qui utilisent MySQL pour distribuer de la nourriture.

Il est un peu injuste d'exiger que MySQL se tienne toujours à un niveau très élevé, car le succès de l'open source peut être un piège. C’est simplement parce que cela peut être gratuit au départ, mais cela ne veut pas dire qu’il peut toujours en être ainsi. Si les entreprises souhaitent de nombreuses nouvelles fonctionnalités, elles devront les payer d’une manière ou d’une autre. Parfois, il est moins coûteux de payer Oracle que d'écrire le code vous-même. Parfois, du code commercial non open source a du sens. Les faits parlent d'eux-mêmes.

Ce qui précède sont les 8 pièges MySQL qui doivent être mentionnés. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !