MongoDB Tables Scheme Design - Meilleure pratique. Utiliser des documents maîtres (comme dans les tables maîtres rdbms) ou non

Question

Contexte: Je prototypage l'utilisation de MongoDB dans mon projet où j'utilise des tables principales pour stocker des définitions et utiliser ces clés dans des tables de données. mes quelques tables maîtres sont

Class Master_Feed_Provider { int key; 
string feed_provider_name 
string address } 

Class Master_File_Types {int id; 
string type } 

Ma table de données est

Class Data_Feeds {int id, 
int file_type_key , int feed_provider_key , 
DateTime time } 

** J'utilise ici feed_provider_key pour relier les détails de master_feed_provider

Voici donc mon doute est MongoDB supporte ce genre de conception, mais devrais-je aller pour cette conception ou je devrais juste garder les détails complets de feed_provider et file_types dans mes entrées de table data_feed à la place des seules clés et récupérer des informations en utilisant les jointures? Garder tous les détails dans mes tableaux de données (à la place de la seule clé) augmentera la taille des données. et Conserver les touches et utiliser les jointures pour lier les détails entraînera des opérations db supplémentaires. Alors, quel est le meilleur moyen ici?

Answer 1

tout d'abord: il n'y a pas « Ce est la bonne façon de le faire dans mongo » contrairement à SGBDR. Chaque décision prise doit être basée sur le bon sens. Voici le lien décrivant les décisions de conception possibles: link. Comme il dit il y a 2 options: Masterfeeds:

1)

masterfeeds: 

{ _id: idValue, 
    name: nameValue, 
    masterFileTypes:[typeId1, typeId2, typeId3]} 

masterFileTypes: 
    { _id: idValue, 
    Type: typeValue, 
    masterFeeds:[mfId1, mfId2, mfId3]} 

2)

masterfeeds: 
     { _id: idValue, 
     name: nameValue, 
     masterFileTypes: [typeId1, typeId2, typeId3]} 

masterFileTypes: 
    { _id: idValue, 
    Type: typeValue} 

Answer 2

Vous devriez examiner les valeurs ObjectId pour vos clés. Votre question est un peu difficile à comprendre, mais MongoDB peut prendre en charge un modèle relationnel traditionnel MAIS parce qu'il n'y a pas de jointures dans la base de données que vous devez faire dans votre application et cela signifie généralement plusieurs requêtes à la base de données. A la place, vous voulez généralement dénormaliser les données et éventuellement stocker une copie des champs dont vous avez besoin pour satisfaire la demande en moins d'allers-retours.

Voir MongoDB: Should you still provide IDs linking to other collections to or just include collections?

Answer 3

Il se résume essentiellement le si vous souhaitez intégrer (sous-document) ou un lien (un autre document de collection)? Jetez un oeil à how to structure many-to-many relationships in mongoose? pour les avantages et les inconvénients de chaque approche.