Je suis en train de créer un site qui est une communauté de location immobilière, dont les fonctionnalités principales sont centrées sur des discussions spécifiques à chaque ville. Il y aura des données utilisateur indiquant les villes qu’ils connaissent bien et leur relation avec ces villes (actuellement résident, y ont vécu, etc.), et les utilisateurs pourront également s’abonner aux villes dans lesquelles ils souhaitent investir mais qu’ils ne connaissent pas bien. Toutes les villes seront des catégories, avec un champ personnalisé pour stocker leurs données géocodées afin que les utilisateurs puissent parcourir les villes sur une carte.
Ce qui me fait hésiter, c’est la manière dont je devrais structurer cela d’un point de vue de l’efficacité de la base de données. Lorsque vous êtes sur une page de ville, j’afficherai un flux montrant les « experts membres » de cette ville. Si je dois interroger tous les utilisateurs et parcourir leurs champs personnalisés et le hash du champ personnalisé « villes d’expertise » à chaque fois que je rends une page de catégorie, je pense que ce serait assez lent, surtout à mesure que le nombre d’utilisateurs et de villes augmente.
Si je devais construire cela dans mon propre application Rails, ce problème serait facilement résolu avec des tables de jointure et des relations has_many_through ou quelque chose de similaire. Ce que je me demande ici, c’est quelle est l’approche recommandée pour un plugin qui nécessite une table de jointure. Il semble que les migrations et les tables personnalisées soient déconseillées et qu’il soit généralement préférable d’utiliser soit des champs personnalisés, soit PluginStore — je n’ai pas réussi à trouver de documentation réelle sur PluginStore, mais je suis actuellement en train de creuser.
J’ai pensé qu’il serait sage de demander l’approche « officiellement recommandée par Discourse » avant de m’engager trop loin dans une direction particulière.
Merci 
Zach
