Points de base
$lookup dans la version 3.2, qui peut effectuer des opérations de type gauche sur deux ensembles ou plus, réalisant ainsi des données similaires aux bases de données relationnelles. Cependant, cet opérateur est limité à l'utilisation dans les opérations agrégées, qui sont plus complexes et généralement plus lentes que les requêtes de recherche simples. $lookup nécessite quatre paramètres: localField (saisir le champ de recherche dans le document), from (la collection à connecter), foreignField (les champs se trouvent dans la collection de from) et as (nom du champ de sortie). Cet opérateur peut être utilisé dans les requêtes agrégées pour faire correspondre les publications, trier dans l'ordre, limiter le nombre d'éléments, connecter les données de l'utilisateur, aplatir les tableaux d'utilisateur et retourner uniquement les champs nécessaires. $lookup de MongoDB soit utile et puisse aider à gérer une petite quantité de données relationnelles dans une base de données NoSQL, elle ne remplace pas la clause de jointure plus puissante dans SQL. Si le document utilisateur est supprimé dans MongoDB, le document de publication orphelin sera conservé, indiquant un manque de contraintes. Par conséquent, si l'opérateur $lookup est fréquemment utilisé, il peut indiquer que le mauvais stockage de données est utilisé et qu'une base de données relationnelle (SQL) peut être plus appropriée. Merci à Julian Motz pour son aide à l'examen par les pairs.
L'une des plus grandes différences entre les bases de données SQL et NOSQL est la jointure. Dans une base de données relationnelle, la clause de jointure SQL vous permet de combiner des lignes à partir de deux tables ou plus en utilisant un champ commun entre eux. Par exemple, si vous avez une table de livre et d'éditeur, vous pouvez écrire la commande SQL suivante:
SELECT book.title, publisher.name FROM book LEFT JOIN book.publisher_id ON publisher.id;
En d'autres termes, le tableau du livre a un champ Publisher_id qui fait référence au champ ID dans la table des éditeurs.
Ceci est pratique car un seul éditeur peut fournir des milliers de livres. Si nous devons mettre à jour les détails de l'éditeur à l'avenir, nous pouvons modifier l'enregistrement individuel. La redondance des données est minimisée car nous n'avons pas besoin de répéter les informations de l'éditeur pour chaque livre. Cette technologie est appelée standardisation.
Les bases de données SQL fournissent une gamme de normalisation et de contraintes pour assurer la maintenance des relations.
Ce n'est pas toujours le cas…
Les bases de données axées sur le document (telles que MongoDB) sont conçues pour stocker des données dés-normalisées. Idéalement, il ne devrait pas y avoir de relation entre les ensembles. Si les mêmes données doivent être dans deux ou plusieurs documents, elles doivent être répétées.
Cela peut être frustrant car il n'y a presque aucune situation où vous n'aurez jamais besoin de données relationnelles. Heureusement, MongoDB 3.2 a introduit un nouvel opérateur qui peut effectuer des opérations de type gauche sur deux ensembles ou plus. Mais il y a un problème ... $lookup
$lookup autorisé uniquement à être utilisé dans les opérations agrégées. Considérez-le comme un pipeline d'une série d'opérateurs qui interrogent, filtrent et groupes de groupe. La sortie d'un opérateur est utilisée comme entrée pour l'opérateur suivant.
Les agrégations sont plus difficiles à comprendre que les requêtes de recherche simples et fonctionnent généralement plus lentement. Cependant, ils sont puissants et sont une option précieuse pour les opérations de recherche complexes.
Il est préférable d'utiliser un exemple pour expliquer l'agrégation. Supposons que nous créons une plate-forme de médias sociaux avec une collection d'utilisateurs. Il stocke les détails de chaque utilisateur dans un document séparé. Par exemple:
SELECT book.title, publisher.name FROM book LEFT JOIN book.publisher_id ON publisher.id;
Nous pouvons ajouter autant de champs que nous le souhaitons, mais tous les documents MongoDB nécessitent un champ _id avec une valeur unique. _id Similaire aux clés primaires SQL, elles seront insérées automatiquement si nécessaire.
Notre réseau social a maintenant besoin d'une collection de publications qui stockent un grand nombre de mises à jour perspicaces des utilisateurs. Le document stocke le texte, la date, la notation et les références à l'utilisateur qui l'a écrit dans le champ user_id:
{
"_id": ObjectID("45b83bda421238c76f5c1969"),
"name": "User One",
"email": "userone@email.com",
"country": "UK",
"dob": ISODate("1999-09-13T00:00:00.000Z")
}Nous voulons maintenant afficher les vingt derniers messages évalués "importants" par tous les utilisateurs dans l'ordre inverse du temps. Chaque document renvoyé doit contenir du texte, l'heure de la publication et le nom et le pays de l'utilisateur associé.
La requête d'agrégation MongoDB passe un tableau d'opérateurs de pipeline qui définissent chaque opération dans l'ordre. Tout d'abord, nous devons utiliser le filtre $match pour extraire tous les documents avec des notes correctes de la collection de post:
{
"_id": ObjectID("17c9812acff9ac0bba018cc1"),
"user_id": ObjectID("45b83bda421238c76f5c1969"),
"date": ISODate("2016-09-05T03:05:00.123Z"),
"text": "My life story so far",
"rating": "important"
} Nous devons maintenant trier les éléments correspondants dans l'ordre inverse en utilisant l'opérateur $sort:
{ "$match": { "rating": "important" } } Comme nous n'avons besoin que de vingt messages, nous pouvons appliquer la stade $limit afin que MongoDB ne soit que pour traiter les données que nous voulons:
{ "$sort": { "date": -1 } } Nous pouvons désormais utiliser le nouvel opérateur $lookup pour connecter les données de la collecte des utilisateurs. Il nécessite un objet avec quatre paramètres:
localField: Entrez le champ de recherche dans le document from: Collection à connecter foreignField: champs trouvés dans from collection as: le nom du champ de sortie. Par conséquent, notre opérateur est:
{ "$limit": 20 } Cela créera un nouveau champ dans notre sortie appelée userinfo. Il contient un tableau où chaque valeur correspond au document utilisateur:
{ "$lookup": {
"localField": "user_id",
"from": "user",
"foreignField": "_id",
"as": "userinfo"
} } Nous avons une relation un à un post.user_id et user._id parce qu'un message ne peut avoir qu'un seul auteur. Par conséquent, notre tableau userinfo ne contiendra toujours qu'un seul élément. Nous pouvons utiliser l'opérateur $unwind pour le décomposer en un sous-document:
"userinfo": [
{ "name": "User One", ... }
]La sortie sera désormais convertie en un format plus pratique, avec d'autres opérateurs disponibles pour postuler:
{ "$unwind": "$userinfo" } Enfin, nous pouvons utiliser la stade $project dans le pipeline pour retourner le texte, l'heure du poste, le nom de l'utilisateur et le pays:
SELECT book.title, publisher.name FROM book LEFT JOIN book.publisher_id ON publisher.id;
Notre requête globale finale correspond aux publications, trie dans l'ordre, limite les vingt derniers éléments, connecte les données utilisateur, afflige les tableaux d'utilisateurs et ne renvoie que les champs nécessaires. Commande complète:
{
"_id": ObjectID("45b83bda421238c76f5c1969"),
"name": "User One",
"email": "userone@email.com",
"country": "UK",
"dob": ISODate("1999-09-13T00:00:00.000Z")
}Le résultat est une collection de vingt documents pouvant aller. Par exemple:
{
"_id": ObjectID("17c9812acff9ac0bba018cc1"),
"user_id": ObjectID("45b83bda421238c76f5c1969"),
"date": ISODate("2016-09-05T03:05:00.123Z"),
"text": "My life story so far",
"rating": "important"
} MongoDB $lookup est utile et puissant, mais même cet exemple de base nécessite une requête d'agrégation complexe. Il ne peut pas remplacer la clause de jointure la plus puissante dans SQL. MongoDB ne fournit pas non plus de contraintes; si le document utilisateur est supprimé, le document de publication orphelin sera conservé.
Idéalement, l'opérateur $lookup doit être rarement nécessaire. Si vous en avez besoin fréquemment, vous avez peut-être utilisé le mauvais magasin de données ...
Si vous avez des données relationnelles, veuillez utiliser une base de données relationnelle (SQL)!
c'est-à-dire $lookup est un ajout populaire à MongoDB 3.2. Il surmonte certains des problèmes les plus frustrants lors de l'utilisation d'une petite quantité de données relationnelles dans une base de données NOSQL.
Dans une base de données SQL, l'opération de connexion combine des lignes de deux tables ou plus en fonction des colonnes associées entre elles. Cependant, MongoDB, en tant que base de données NOSQL, ne prend pas en charge les connexions SQL traditionnelles. Au lieu de cela, MongoDB fournit deux façons d'effectuer des opérations similaires: l'étape $lookup et l'étape $graphLookup dans l'agrégation. Ces méthodes vous permettent de combiner des données de plusieurs collections en un seul ensemble de résultats.
$lookup
L'étape dans MongoDB vous permet de connecter des documents à partir d'une autre collection (collection "connectée") et d'ajouter les documents connectés au document d'entrée. La phase $lookup spécifie la "collection," Localfield "et" Foreignfield "pour correspondre au document, et le champ" AS "pour produire le document. Il est similaire à la jointure extérieure gauche dans SQL, renvoyant tous les documents de la collection d'entrée et des documents de correspondance de la collection "From". $lookup
pour la recherche récursive. L'étape $graphLookup effectue une recherche récursive sur l'ensemble spécifié et peut choisir de limiter la profondeur et l'étendue de la recherche. Il est utile pour interroger des données hiérarchiques ou des graphiques où le nombre de niveaux est inconnu ou peut changer. $graphLookup
et $lookup étapes pour filtrer et convertir des documents. $match
Oui, vous pouvez connecter plusieurs collections MongoDB en reliant plusieurs étapes $lookup dans un pipeline d'agrégation. Chaque étape $lookup ajoute des documents connectés d'une autre collection au document d'entrée.
Lors de l'utilisation de la connexion MongoDB, si le document dans la collection d'entrée ne correspond à aucun document dans la collection "From", la phase $lookup ajoute un tableau vide au champ "AS". Vous pouvez gérer ces valeurs nulles ou manquantes en ajoutant la phase $lookup après la phase $match pour filtrer les documents avec des champs vides "comme" champs.
En commençant par MongoDB 3.6, les étapes $lookup et $graphLookup peuvent accepter les ensembles frappés comme "à partir de" ensembles. Cependant, en raison de la surcharge supplémentaire du réseau, les performances peuvent ne pas être aussi bonnes que les collections non ravières.
Vous pouvez trier les documents connectés dans MongoDB en ajoutant la phase $lookup après la phase $sort dans le pipeline d'agrégation. La scénario $sort trie les documents dans le champ spécifié dans l'ordre croissant ou descendant.
find()? Non, la connexion MongoDB ne peut pas être utilisée avec la méthode find(). Les étapes $lookup et $graphLookup font partie du cadre d'agrégation qui fournit des capacités de traitement des données plus avancées que la méthode find().
Pour déboguer ou dépanner les défaillances de connexion MongoDB, vous pouvez utiliser la méthode explain() pour analyser le plan d'exécution du pipeline agrégé. La méthode explain() fournit des informations détaillées sur l'étape, y compris le nombre de documents traités, le temps passé et l'utilisation de l'index.
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
