NoSQL prend rarement entièrement en charge la fonction Join, donc la forme dénormalisée est généralement utilisée pour stocker la relation développée dans NoSQL, de sorte que la relation n'est plus "plusieurs-à-un" mais "un-à-plusieurs".

Vous pouvez utiliser des types de collection pour stocker des sous-documents, tels qu'une liste ou un ensemble dans Redis, un sous-document dans MongoDB, etc.

Pour NoSQL, il existe un principe simple, qui consiste à regrouper les éléments liés, tels que les articles et les commentaires. Notez que si possible, essayez de regrouper tous les attributs, y compris le contenu, des articles et des commentaires, plutôt que simplement Store. l'identifiant du commentaire dans l'enregistrement de l'article.
L'avantage de ceci est évident. Vous n'avez besoin que d'une seule opération de lecture pour obtenir toutes les données liées à cet article. Quelle que soit la manière dont vous segmentez les données, l'article et les éléments associés ne seront pas séparés en différentes machines physiques. efficace. Améliore considérablement l’évolutivité du backend.
Bien entendu, une telle conception peut ne pas toujours être adaptée à votre application. Par exemple, la relation entre les articles et les auteurs peut ne pas être complètement dénormalisable, vous devez donc examiner attentivement la méthode et le processus de présentation des données pour décider comment organiser les données.

En bref, NoSQL n'est pas une panacée. Bien qu'il offre une flexibilité, une évolutivité et des performances supérieures, il simplifie également la base de données boîte noire d'origine en un moteur de stockage boîte blanche. Vous devez prendre en compte vous-même divers facteurs. Point d'équilibre le plus approprié, ce travail nécessite beaucoup d'expérience et une compréhension approfondie du métier.

Bien sûr, ce n'est pas un problème si la quantité de données est faible.

Utiliser la liste ?

N'est-il pas possible d'utiliser set ? Mettez l'identifiant des commentaires dans un post_id: set.