Sous-documents Mongoose vs schéma imbriqué

Question

Je suis curieux de connaître les avantages et les inconvénients de l'utilisation de sous-documents par rapport à une couche plus profonde dans mon schéma principal :

var subDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [subDoc]
});

o

var mainDoc = new Schema({
  names: [{
    name: String
 }]
});

J'utilise actuellement des subdocs partout, mais je m'interroge surtout sur les problèmes de performances ou de requêtes que je pourrais rencontrer.

Answer 1

Selon les docs c'est exactement la même chose. Cependant, l'utilisation d'un schéma ajouterait un _id (tant que vous ne l'avez pas désactivé), et utilise vraisemblablement un peu plus de ressources pour le suivi des sous-docs.

Syntaxe de déclaration alternative

Nouveau dans la v3 Si vous n'avez pas besoin d'accéder à l'instance de schéma de sous-document, vous pouvez également déclarer des sous-documents en passant simplement un objet littéral [...].

Answer 2

Si vous avez des schémas qui sont réutilisés dans diverses parties de votre modèle, il peut être utile de définir des schémas individuels pour les documents enfants afin de ne pas avoir à les dupliquer.

Answer 3

Vous devez utiliser les documents intégrés s'il s'agit de documents statiques ou s'ils ne dépassent pas quelques centaines de pages en raison de l'impact sur les performances. J'ai déjà abordé cette question il y a un certain temps. Récemment, Asya Kamsky, qui travaille comme architecte de solutions pour MongoDB, a écrit un article sur l'utilisation des sous-documents.

J'espère que cela aidera ceux qui cherchent des solutions ou les meilleures pratiques.

Article original sur http://askasya.com/post/largeembeddedarrays . Vous pouvez accéder à son profil stackoverflow sur https://stackoverflow.com/users/431012/asya-kamsky

Tout d'abord, nous devons nous demander pourquoi nous voudrions faire une telle une telle chose. Normalement, je conseillerais aux gens d'incorporer des choses qu'ils veulent toujours récupérer quand ils vont chercher ce document. Le revers de la médaille l'envers de la médaille est que vous ne voulez pas intégrer des choses dans le document que vous ne voulez pas récupérer avec le document.

Si vous intégrez l'activité que je réalise dans le document, cela fonctionnera très bien à d'abord parce que toute mon activité est juste là et avec une seule lecture vous pouvez récupérer tout ce que vous voulez me montrer : "vous avez récemment cliqué sur ceci et voici vos deux derniers commentaires" mais que se passe-t-il mais que se passe-t-il quand six mois passent et que je me moque de ce que j'ai fait il y a longtemps ? il y a longtemps et que tu ne veux pas me les montrer à moins que je ne cherche spécifiquement à rechercher une ancienne activité ?

D'abord, vous finirez par renvoyer des documents de plus en plus gros et à soigner d'une partie de plus en plus petite de celui-ci. Mais vous pouvez utiliser la projection pour pour ne renvoyer qu'une partie du tableau, le problème étant que le document sur le disque le document sur le disque va devenir plus gros et il sera toujours lu en entier même si vous ne faites que même si vous n'en retournez qu'une partie à l'utilisateur final, mais puisque mon activité ne va pas s'arrêter tant que je suis actif, le document va continuer à à croître et à grandir.

Le problème le plus évident est que vous finirez par atteindre les 16 Mo. mais ce n'est pas du tout ce qui doit vous préoccuper. l'inquiétude. Un document qui s'agrandit continuellement entraînera des coûts de plus en plus élevés à chaque fois qu'il devra être déplacé. coût de plus en plus élevé à chaque fois qu'il doit être déplacé sur le disque, et même si vous prenez des pour atténuer les effets de la fragmentation, vos écritures seront globalement écrites seront dans l'ensemble inutilement longues, ce qui aura un impact sur les performances l'ensemble de votre application.

Il y a encore une chose que vous pouvez faire qui va complètement tuer votre performance de votre application, et c'est d'indexer ce tableau toujours croissant toujours plus grand. Ce que cela signifie, c'est qu'à chaque fois que le document avec ce tableau est déplacé, le nombre d'entrées d'index qui doivent être mises à jour mises à jour est directement proportionnel au nombre de valeurs indexées dans le document. ce document, et plus le tableau est grand, plus ce nombre sera important sera plus grand.

Je ne veux pas que cela vous effraie et que vous n'utilisiez pas les tableaux alors qu'ils sont une bonne solution. modèle de données - ils sont une caractéristique puissante du modèle de données de la base de de base de données, mais comme tout outil puissant, il faut l'utiliser dans les bonnes circonstances et il faut l'utiliser avec précaution.

Answer 4

En gros, créez une variable nestedDov et le mettre ici name: [nestedDov]

Version simple :

var nestedDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [nestedDoc]
});

Exemple JSON

{
    "_id" : ObjectId("57c88bf5818e70007dc72e85"),
    "name" : "Corinthia Hotel Budapest",
    "stars" : 5,
    "description" : "The 5-star Corinthia Hotel Budapest on the Grand Boulevard offers free access to its Royal Spa",
    "photos" : [
        "/photos/hotel/corinthiahotelbudapest/1.jpg",
        "/photos/hotel/corinthiahotelbudapest/2.jpg"
    ],
    "currency" : "HUF",
    "rooms" : [
        {
            "type" : "Superior Double or Twin Room",
            "number" : 20,
            "description" : "These are some great rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/2.jpg",
                "/photos/room/corinthiahotelbudapest/5.jpg"
            ],
            "price" : 73000
        },
        {
            "type" : "Deluxe Double Room",
            "number" : 50,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 92000
        },
        {
            "type" : "Executive Double Room",
            "number" : 25,
            "description" : "These are amazing rooms",
            "photos" : [
                "/photos/room/corinthiahotelbudapest/4.jpg",
                "/photos/room/corinthiahotelbudapest/6.jpg"
            ],
            "price" : 112000
        }
    ],
    "reviews" : [
        {
            "name" : "Tamas",
            "id" : "/user/tamas.json",
            "review" : "Great hotel",
            "rating" : 4
        }
    ],
    "services" : [
        "Room service",
        "Airport shuttle (surcharge)",
        "24-hour front desk",
        "Currency exchange",
        "Tour desk"
    ]
}

Ejemplo:

Answer 5

Je pense que cette question est traitée ailleurs par de nombreux messages sur le SO.

Juste quelques-uns :

• Relations dans MongoDB : intégration ou référence ?
• Comment dois-je mettre en œuvre ce schéma dans MongoDB ?
• Conception de schémas MongoDB - Beaucoup de petits documents ou moins de gros documents ?

L'essentiel est qu'il n'y a pas de réponse unique, mais un ensemble de compromis assez complexes.