Résumez quelques pièges de MySQL

Cette fois, je vais vous présenter un résumé de quelques pièges MySQL. Quelles sont les précautions lors de l'utilisation de MySQL Voici des cas réels, jetons un coup d'œil. L'

MysqlL'installation est simple, 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 levé 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.

1. Bogues profondément enracinés

Tout logiciel volumineux contient des bogues. Mais si vous creusez un peu plus, vous constaterez que les bugs liés à Mysql ont leur propre système. 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.

2. Inflexibilité des tables relationnelles

Les tables relationnelles sont organisées, et l'organisation est bonne - mais cela oblige les programmeurs à inventer ou à forcer le remplissage de certaines données dans une colonne avec un schéma défini. 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.

3. JOINRequê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 de fonctionnement 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 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.

4. 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 apporter de la confusion et de 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 ? Devrions-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 pouvons-nous obtenir 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.

5. 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, et la plupart de leurs détails sont couverts par une surface unifiée ; couverture. 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 ?

6. Motivation du profit

Bien que MySQL soit un produit open source à succès, c'est toujours une entreprise pleine de professionnels qui comptent sur lui pour être un développeur rémunéré. 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 équitable 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 ?

7. Manque de support JSON natif

En regardant l'âge de MySQL, le meilleur moyen est de l'installer et vous vous rendrez alors compte que vous devez ajouter plus de pilotes pour le faire fonctionner Il est disponible. MySQL communique généralement sur le port 3306 et génère généralement des données formatées qu'il a du mal à 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 les interfaces JSON natives sont déjà largement disponibles dans CouchDB, MongoDB ou l'un des outils les plus récents.

8. L'essor des modules 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.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php. !

Lecture recommandée :

Vue créant un carrousel d'images

JS obtient la valeur dans le premier élément de la liste déroulante de sélection

Comment gérer l'échec de l'installation d'Electron

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!