Un petit MFC se connecte à la base de données MySQL pour se connecter à l'instance via ODBC
Fichier: n459.com/file/25127180-479633004 Mot de passe d'accès: 551685
Les éléments suivants ne sont pas pertinents:
-------------------------------------------Ligne de séparation----- ----------------------------------------
En fait, j'ai voulu écrire très tôt des articles sur les bases de données distribuées, c'est ce que j'étudie actuellement, et c'est aussi quelque chose qui m'intéresse beaucoup. Mais quand il s'agit de bases de données distribuées, de nombreux détails techniques pertinents entrent en jeu. Lorsque les détails pertinents sont clairement écrits, plus d'une douzaine d'articles ont passé XD. Donc, si vous voulez comprendre les détails techniques de l'arbre B / B +, LSMT, CAP, etc., vous pouvez lire l'article précédent. Aujourd'hui, nous allons parler du concept de NoSQL.
La signification générale de
noSQL NoSQL est maintenant très populaire . Neuf des dix CV que j'ai lus sont familiers avec noSQL, mais peu de gens peuvent expliquer les détails de noSQL, même ce que le no in noSQL signifie Beaucoup de gens font une erreur. Ce non ne veut pas dire non, mais une abréviation de non seulement. Je dois dire que cet acronyme est vraiment de la triche, personne ne devrait être capable de deviner ce que cela signifie littéralement. Et même s'il est interprété non seulement comme du SQL, il est encore un peu obscurci et il n'est pas très précis pour comprendre son point.
Parce que le mot anglais pour SQL est un langage de requête structuré, ce qui signifie un langage de requête structuré. Il peut être considéré comme un langage de programmation spécial, mais que signifie «pas seulement SQL»? C'est vraiment déroutant, donc nous ne pouvons pas le comprendre littéralement, nous devons le comprendre à partir de scénarios d'application réels.
Les scénarios d'application SQL sont des bases de données relationnelles, telles que Oracle et MySQL couramment utilisés, qui sont des bases de données relationnelles. Quand on comprend la base de données, on commence souvent par la structure de la table pour comprendre. Ce qui est stocké dans la base de données est une feuille de tables, une table est composée de lignes de données et chaque ligne de données a un champ fixe. Je pense que tout le monde devrait être très familier avec ce point, même si vous n'avez pas appris la base de données ou si vous êtes revenu vers le professeur comme moi, vous devriez avoir plus ou moins d'impression.
Mais pourquoi est-il appelé une base de données relationnelle au lieu d'une base de données de structure de table?
Parce que dans la base de données, la relation est plus importante que la structure de la table. La structure de la table n'est qu'un formulaire et le concept de conception de base dans la base de données est en fait une relation. C'est pourquoi nous devons tous partir du diagramme ER lorsque nous apprenons la base de données, au lieu de parler de la méthode d'utilisation de la base de données ou des détails du langage SQL. Si vous ne comprenez pas le sens de cette phrase, peu importe, mettons-la de côté en premier et revenons enfin à ce sujet.
La question est, nous savons que la base de données SQL couramment utilisée est une base de données relationnelle, alors quelle est la base de données représentée par noSQL?
J'ai vu au moins deux déclarations sur le concept de noSQL, l'une est une base de données non relationnelle et l'autre une base de données de documents. Quand je le comprends personnellement, j'ai le sentiment que ces deux déclarations ne sont pas parfaites, mais en comparaison, la deuxième déclaration est évidemment meilleure, car la première déclaration ne nous fournit aucune information. Le document dans la base de données de documents n'est pas la signification d'un document que nous comprenons habituellement, mais fait référence à la structure et à la logique de base du stockage des données.
Un exemple frappant
Comme la plupart des concepts techniques, noSQL est relativement obscur et il est difficile de le décrire clairement dans le langage. J'ai donc décidé de citer un exemple vivant que tout le monde connaît: le trésor X omnipotent.
Ce qui suit est une image de la page de détails du produit dans X treasure (sélectionnez-la à volonté, pas une publicité, s'il y a une coïncidence, veuillez payer les frais de promotion):
Tout le monde doit être familier avec cette image, nous l'avons vue plusieurs fois dans nos activités habituelles de magasinage en ligne. Cela semble un peu éblouissant. Nous avons résumé et condensé le contenu ci-dessus et l'avons dessiné dans un croquis. Cela ressemble à ceci (c'est un peu bâclé):
C'est-à-dire que nous divisons grossièrement le contenu affiché sur une page de détail du produit en trois parties, une partie est l'image du produit, l'autre partie est la description du produit et l'autre partie est le commentaire de l'utilisateur. La conception des pages de détails des produits des principales sociétés de commerce électronique est similaire, et certains détails peuvent être différents, mais les modules globaux ne sont pas très différents.
Afin de simplifier le problème, nous supposons que la page de détail du produit doit associer trois tableaux d'informations sur l'image, la description textuelle et les commentaires des utilisateurs. En fait, cette division n'est pas scientifique. Par exemple, la description textuelle et la carte du produit peuvent être stockées dans le tableau de la page de détail du produit. Par exemple, en plus de ces informations, il existe également des informations sur les ventes de produits, telles que l'inventaire, les prix, les offres en cours, les activités, etc. Mais ceux-ci n'ont pas grand-chose à voir avec nos conclusions finales et peuvent être simplement compris comme tels.
Selon la méthode de division ci-dessus, nous devons rechercher les informations sur l'image, le texte et les commentaires du produit en fonction de l'itemId, ce qui ne pose bien sûr aucun problème en surface. Mais en fait, cela pose problème: le problème est que ces données ne sont pas une relation un-à-un, mais une relation un-à-plusieurs.
Par exemple, il y a souvent plus d'une image affichée sur l'en-tête, et le texte peut avoir plus d'un paragraphe, et le même utilisateur peut avoir plus d'un commentaire. Comment résoudre ce problème?
Vous pouvez trouver un moyen. Ce n'est pas difficile. Nous ajoutons le champ itemId aux tables img, text et comment, et l'associons à itemId lorsque nous interrogeons, n'est-ce pas?
En supposant que vous êtes le programmeur responsable de ce projet, vous avez effectué cette mise à jour, et après le lancement réussi, le produit vous met dans une nouvelle demande. Elle a dit que je voulais afficher des images à la fois dans l'introduction du texte et dans les commentaires des utilisateurs. Bien que le système n'ait pas été conçu comme ça au début, je m'en fiche. J'en ai juste besoin.
Vous avez roulé des yeux pendant un moment, vous vous êtes calmé pendant un long moment, et après y avoir réfléchi, vous avez finalement pensé à deux options. La première consiste à ajouter un champ à la table d'images courante pour déterminer si l'image est utilisée pour l'affichage de la page de détail ou pour le commentaire. L'affichage de la page, l'introduction de texte à ajouter ultérieurement et l'image dans la page de commentaires existent toujours sur ce tableau. Le deuxième plan est de reconstruire une nouvelle table, dédiée à la table spéciale, chargée de stocker les images de la page de commentaire et de la page de description.
L'avantage de la première solution est que nous n'avons pas besoin de construire une nouvelle table, ce qui évite la redondance des tables.Si chaque exigence nécessite de construire une nouvelle table, c'est évidemment un énorme fardeau pour la maintenance ultérieure. Mais son inconvénient est que nous devons modifier toutes les données précédentes par lots, car il n'y a pas de champ source dans les données précédentes. Bien sûr, vous pouvez également utiliser id pour distinguer sans ce champ, mais ce n'est pas conforme à la spécification, et cela entraînera inévitablement des risques de sécurité.
L'avantage de la deuxième solution est une opération simple, pas besoin de changer les données précédentes et moins de risque de sécurité, mais le problème est qu'elle doit occuper de nouvelles ressources et le taux d'utilisation est faible, car certaines images de page de détails et les images du haut peuvent être partagées. Si vous les stockez séparément, vous devez stocker plusieurs copies.
Ces deux systèmes ont leurs propres avantages et inconvénients, et les deux semblent bons, mais le piège est qu'ils ont tous un inconvénient commun, c'est-à-dire qu'ils augmenteront la complexité du système et de la requête actuels. L'une consiste à augmenter le nombre de champs transmis lors des requêtes, et l'autre à lancer des requêtes supplémentaires. Quel que soit celui sélectionné, le système deviendra de plus en plus compliqué. Plus tard, lorsqu'une demande d'utilisateur arrive, des dizaines de demandes de liaison seront conduites pour assembler des données complètes. Maintenant, la partie introduction au produit de la dernière version de la page de détails de X treasure est toujours affichée avec des images, sans texte, peut-être est-elle motivée par ce problème derrière elle.
Examinons cet exemple. La raison pour laquelle notre requête est si compliquée est en fait liée au concept de base de la base de données. Les données stockées dans la base de données relationnelle sont la relation. Dans ce problème, nous devons interroger la relation entre le produit et l'image, la relation entre le produit et la description, la relation entre le produit et l'avis, la relation entre l'avis et l'image, etc. En d'autres termes, la page que nous voyons finalement est en fait le résultat de cette série de relations. Derrière chaque requête se cache un processus de décomposition des relations puis de fusion, donc ce sera très compliqué.
Base de données documentaire
Nous venons de regarder les problèmes de base de données relationnelle dans le scénario e-commerce, regardons les performances de la base documentaire dans le même scénario.
Contrairement aux bases de données relationnelles, le noyau du stockage des bases de données de documents est constitué de documents. Bien sûr, le document ici ne fait pas référence au document dans notre sens habituel, mais aux données au format json ou xml. Parmi les bases de données noSQL actuelles, les données json sont plus couramment utilisées. Nous utilisons également l'exemple de la page de détails pour voir comment ces données sont stockées dans la base de données noSQL:
{ "ItemID": 123, "itemName": "iPad Pro", "topImgs": ["imgs1.path", "imgs2.path"], "desc": [{"text": "iPad Pro", " img ":" "}, {" text ":" nouvelle version 2020 "," img ":" imgs1.path "}], " comments ": [{" userName ":" chengzhi "," comment ":" good product "," imgs ": [" imgs3.path "," img4.path "]}] } Vous voyez, dans la base de données de documents, le complexe nécessite maintenant plusieurs requêtes et une série de traitements avant de pouvoir être vissé ensemble Les données peuvent être obtenues par une requête via itemID.
Pour parler simplement, c'est beaucoup plus pratique que les bases de données relationnelles, mais ce n'est pas sans défauts. L'un des gros problèmes est que nous stockons toutes les données directement dans le document, ce qui d'une part entraîne une redondance des données, d'autre part, cela limite également l'évolutivité. Par exemple, des produits similaires sous le même marchand ne peuvent pas partager de photos, mais doivent stocker plusieurs copies, ce qui entraîne un gaspillage d'espace. Pour un autre exemple, supposons que nous voulions aider les utilisateurs à modifier les commentaires passés avant que cela ne soit très gênant, car nous devons trouver tous les documents qui stockent les commentaires des utilisateurs à modifier (en supposant que les commentaires des utilisateurs sont également utilisés dans d'autres scénarios), qui est souvent intersystème et Très gênant.
Ce problème n'est pas insoluble. Par exemple, nous pouvons remplacer les données spécifiques stockées dans le document par un identifiant. Par exemple, les informations d'image et de commentaire spécifiques ne sont plus stockées dans le commentaire, mais l'identifiant d'un commentaire est stocké, puis associé lors de son utilisation. . En raison de la structure de la base de données de documents, la prise en charge de l'association n'est pas bonne, et nous devons souvent interroger manuellement en fonction de l'ID pour simuler la connexion, ce qui entraînera également une surcharge supplémentaire.
Un autre petit défaut est que le chemin d'accès aux données dans la base de données documentaire est devenu plus long. Par exemple, ajoutez que nous voulons obtenir la première image dans le deuxième article de la revue de produit. Nous devons écrire l'item ['comments'] [1] ['imgs'] [0], et dans les bases de données relationnelles, puisque les images sont directement interrogées via des relations, c'est plus pratique.
En plus de cela, les années de développement des bases de données noSQL sont beaucoup plus courtes que celles des bases de données relationnelles plus matures telles que MySQL, de sorte que les fonctionnalités prises en charge sont relativement petites.
Résumé
À travers un exemple, nous avons comparé de manière vivante la différence entre les bases de données relationnelles et les bases de données noSQL. Revenons à la question du début de l'article: pourquoi faut-il commencer par le diagramme ER lors de l'apprentissage de la base de données, au lieu d'apprendre directement le principe de la base de données et son utilisation?
Je pense qu'après avoir compris l'exemple ci-dessus, il devrait être beaucoup plus facile d'examiner ce problème. Parce que la logique de base d'une base de données relationnelle est de stocker les relations, les spécifications d'utilisation, diverses techniques et fonctionnalités sont essentiellement développées autour de ce noyau. Si nous utilisons la base de données sans accéder à cette couche, il est facile de s'égarer. C'est de combien d'opérations impensables proviennent. Par exemple, quelqu'un stocke le code de la page frontale dans la base de données, comme la concaténation de l'ID dans une chaîne pour stocker plusieurs Valeur et ainsi de suite. Cela montre également que le contenu du manuel classique n’a pas de sens et que chaque chapitre a son rôle prévu. Par conséquent, lorsque nous estimons qu’un contenu est inutile, il se peut que le manuel ne soit pas faux, mais nous ne l’avons pas bien compris.