Mongoid stocke les documents intégrés et les attributs Hash à peu près de la même manière au niveau de la base de données. C'est normal lorsque vous travaillez avec mongoid pour déclarer vos champs dans vos modèles, donc si vous avez une structure imbriquée, c'est normal de créer un document intégré. Parce que MongoDB est sans schéma, mongoid a besoin que vous déclariez des champs afin de les présenter dans le même type d'API qu'ActiveRecord. Mais pour certains cas d'utilisation, un attribut Hash vous donne un peu plus de flexibilité. L'inconvénient de cette flexibilité est que vous êtes limité à l'API Hash, vous n'obtenez donc pas de méthodes d'attribut générées automatiquement et vous ne pouvez pas encapsuler la logique métier comme vous le feriez normalement dans une classe de modèle.
Par exemple, supposons que vous disposiez d'un modèle Questionnaire dans lequel vous devez stocker de nombreuses sections contenant de nombreuses paires question-réponse. Si une exigence clé du système est que l'administrateur puisse configurer de nouvelles sections et questions, vous ne pourrez pas facilement modéliser les réponses sous la forme d'un document intégré standard contenant des champs explicites pour chaque question. Pour ce genre de chose, un hachage pourrait avoir plus de sens.
Je ne sais pas quelles sont vos exigences spécifiques, mais à titre indicatif, je dirais que lorsque vous travaillez avec un schéma fixe, restez fidèle à un document intégré, mais lorsque vous avez besoin d'un modèle ouvert, considérez les attributs Hash.
