MongoDB relation conditionnelle

Question

Supposons que j'ai 4 collections suivantes: 1- messages 2- entreprises 3- groupes 4- utilisateurs est ma structure Bellow actuelle en post:

et leur relation est:

• Une entreprise a un propriétaire et de nombreux autres membres (collection d'utilisateurs).
• Un groupe compte plusieurs membres (utilisateurs).
• Un utilisateur a beaucoup de messages.
• Un groupe contient de nombreux articles publiés par l'un de ses membres.
• Une entreprise a beaucoup de publications qui sont publiées par son ou ses propriétaires.

Maintenant, j'ai un problème sur le stockage relation des utilisateurs, entreprise et groupe avec la collection de messages.

Bellow est ma structure actuelle:

J'ai décidé d'avoir un champ postable dans mon document de poste, et a un champ type qui sera « utilisateur » ou « groupe » ou « société », et deux autres champs name, et id qui sera la société/le groupe id et la société/le groupe name dans les cas où ce poste appartient à une société ou un groupe mais pas à l'utilisateur type="group" || type="company".

Maintenant, comment puis-je gérer cela pour mapper id comme FK de group et company collection (un champ FK de deux collections)? Est-ce la bonne structure?

Answer 1

Ce que vous avez ici est une association polymorphique. Dans les bases de données relationnelles, il est généralement mis en œuvre avec deux champs, postable_id et postable_type. La colonne type définit la table à interroger et la colonne id détermine l'enregistrement.

Vous pouvez faire la même chose dans mongodb (en fait, c'est ce que vous avez trouvé, moins la convention de nommage). Mais mongodb a un type de champ spécial précisément pour ce type de situations: DBRef. Fondamentalement, c'est un champ d'identification mis à jour. Il porte non seulement l'identifiant, mais aussi le nom de la collection (et le nom de la base de données). Comment puis-je gérer cela pour mapper ID comme FK de la collection de groupe et d'entreprise (un champ FK de deux collections)? Considérant que mongodb n'a pas de jointures et que vous devez charger toutes les références manuellement, je ne vois pas en quoi cela diffère d'un champ FK normal. Juste le nom de collection est stocké dans le champ de type maintenant, au lieu d'être codé en dur.