Bonjour,

Je travaille actuellement sur un projet nodejs utilisant mongoose avec plusieurs schéma, dont : logement et résidence.

Une résidence contient plusieurs logements, donc dans mon schéma logement jai un champ résidence qui contient l'id de la résidence associée.

Dans mon application jai besoin de récupérer la liste des logements associés à la résidence que l'utilisateur sélectionne dans une liste déroulante.

Donc plusieurs solutions : soit au moment où il sélectionne la résidence je demande au serveur la liste des logements associés à cette résidence, soit je fais un champs logements dans le schéma résidence qui contient un tableau de référence vers les logements.

La 2eme solution permet d'avoir la liste de logements beaucoup plus facilement cependant il faut maintenir à jour ce tableau dès qu'on ajoute ou supprime un logement.

En gros est-ce une bonne pratique de faire une "relation 1...n" en ayant des références dans chaque schéma.

J'espère que j'ai été assez clair.

Merci

Il faut à tout prix éviter la seconde solution qui, même si elle paraît plus simple sur l'instant, va te poser des complications de fou par la suite.
Imagine que tu doives mettre à jour unerésidence . Tu vas devoir mettre à jour une tonne d'autres références en même temps.
Ça va être compliqué, lourd à maintenir et surtout source de bugs

Cest bien ce que je pensais. Merci beaucoup

À vue d'oeil je pense que tu t'y prends mal. Tu dis avoir une collection "logements" et une collection "résidence" avec une référence de logement vers résidence. Autrement dit, tu as une clé étrangère. Le problème, c'est que c'est une approche purement relationnelle : tu n'as aucun intérêt à faire ça avec une base orientée document, et pire, c'est contre-productif. Si tu veux garder cette normalisation, passe à une base relationnelle type MySQL ou PostgreSQL. Sinon si tu veux garder Mongo, fais de l'orienté documents : une collection "résidence" qui contient la liste de tous ses logements, quitte à devoir introduire de la redondance. De façon générale dans une base orientée documents on va essayer d'éviter les relations entre collections. S'il y en a, ça veut dire que ton document n'est pas un document et qu'il peut (doit) être dénormalisé.

Je comprend pas ta logique vdd, si tu n'as pas de relations entre les tables tu ne peux rien faire.

Comment fais tu par exemple pour ce schéma tout simple : une table user et une table article.

Tu veux savoir quel user a créé l'article donc tu lui met une "clé étrangère".

Selon ton raisonnement il faudrait que user contienne la liste des articles qu'il a créé ? Et à ce moment là tu ne peux plus du tout faire de requêtes sur tes articles à moins de faire des traitements complexe. Alors imagine sur mon projet qui est un airbnb like, ça serait intégrable, alors qu'avec ma logique c'est très propre et clair.

De toute façon meme les framework basés sur MongoDB utilisent des relations comme ça.

Ca serait ingerable"

WatchItBurn n'a pas tort,

Une base de donnée MongoDB ne suis pas le principe du SQL que l'on retrouve sous MySQL ou PostgreSQL, et bien qu'il soit possible de bidouiller pour faire des relations, ça n'a pas été pensé ainsi à la base.

Le fait est que sous MongoDB, tu n'as pas de "modèle" ou de "table", tu crée une "collection" (équivalent d'une table), qui contient un "document" (équivalent d'une row), et qui peut contenir des sous-documents, ...

Enfaite un document c'est un peu représentable comme un fichier, qui peut en contenir d'autres.

La logique de MongoDB c'est de privilégier par exemple :
Une collection User, contenant un document par User (avec nom, prénom, ...), et si l'utilisateur doit avoir une résidence, il prend également un champ :
"residence" : { ... }

ce champ pouvant contenir des données sur la résidence, et aussi un array "logements" : [ ... ]
qui contiendrais des objets logements.

Après, ce n'est pas forcément le plus gérable, mais c'est plus dans la logique de MongoDB... Pour un projet comme le tiens, je ne vois pas vraiment pourquoi utiliser MongoDB, car les bases SQL (MySQL ou PostgreSQL par exemple) seraient beaucoup plus adaptés, car justement "relationnel".

MongoDB se compare sur son site officiel à MySQL tout en expliquant en quoi ils changent, mais aussi quand il faut privilégier du SQL à Mongo :

https://www.mongodb.com/compare/mongodb-mysql

Après, la logique de MongoDB fait que sans structure, tu peux rajouter des champs à certains documents ou sous documents, ou même à tous, ils ne sont pas obligé d'être basé sur un schéma identique tout en représentant la même chose (il n'y a pas de "columns" fixe dans Mongo).

Et c'est manipulable avec les commandes que propose Mongoose :
http://mongoosejs.com/docs/queries.html
https://stackoverflow.com/questions/16845191/mongoose-finding-subdocuments-by-criteria

Enfin, même si c'est sujet à débat car oui on peut toujours stocker un id et faire un findById sur une autre collection après l'avoir récupéré et donc s'en servir comme relation... ça reste éloigné de ce que conseil MongoDB (et je ne suis pas sûr qu'il y ai d'optimisation sur ce point côté Mongo avec INDEX ou autre, alors que le SQL lui en a...)

Et je ne vois pas pourquoi ne pas utiliser MariaDB/MySQL (ou un autre) à la place de Mongo... (ce n'est pas car on fait du nodejs que l'on doit forcément caser Mongo à chaque fois)

En fait j'utilise MEAN.JS pour mon projet et ils intègrent MongoDB avec des liens entre les différents documents etc.

Je vous laisse regarder le code source de leur github si ça vous intéresse.

IVEOTECH > Azazelbee a raison, pourtant : MongoDB a ses usecase idéaux, de même que MySQL/Postgres.

D'expérience, je préfère travailler sur Mongo quand je joue sur des données par nature flexible et peu relationnelles (une ou deux collections liées entre elles).

Et de même qu'Azazelbee, je constate que beaucoup de dev qui débutent avec node ont tendance à faire le raccourci "on fait du node, donc on utilise Mongo", ce qui est un petit peu étroit comme raisonnement.

Après, je peux juger l'analyser de l'auteur sans connaître tout le projet, mais du peu qu'on en voit, il a l'air de bosser sur un projet fortement relationnel, et je lui conseillerai de partir sur du MySQL ou, mieux, du PostgresQL. Il y a un très très bon ORM pour les deux sur node, qui s'appelle Sequelize.

Désolé, j'ai oublié de passer pour répondre

Le 22 octobre 2016 à 05:42:55 IVEOTECH a écrit :
Je comprend pas ta logique vdd, si tu n'as pas de relations entre les tables tu ne peux rien faire.

Premier point sur lequel j'insiste, ce n'est pas "ma logique", c'est "LA logique NoSQL", et plus précisément "LA logique de l'orienté document".

Comment fais tu par exemple pour ce schéma tout simple : une table user et une table article.

Tu veux savoir quel user a créé l'article donc tu lui met une "clé étrangère".

Non, tu lui mets une clé étrangère quand tu fais du relationnel. Quand tu fais de l'orienté document tu as deux choix : soit tes users ont un champ "articles", soit tes articles ont un champ "créateur(s)". Et je vois venir la remarque donc je réponds : oui, on introduit potentiellement de la redondance. C'est normal en NoSQL. Je t'invite à te renseigner d'abord sur tout ce qui touche à la normalisation de base de données, j'y reviendrais à la fin.

Selon ton raisonnement il faudrait que user contienne la liste des articles qu'il a créé ? Et à ce moment là tu ne peux plus du tout faire de requêtes sur tes articles à moins de faire des traitements complexe. Alors imagine sur mon projet qui est un airbnb like, ça serait intégrable, alors qu'avec ma logique c'est très propre et clair.

Tout à fait, ce n'est pas très pratique, mais c'est comme ça. Ta logique est bonne, et même très bonne, mais c'est une logique relationnelle, pas une logique NoSQL. J'y reviens tout de suite après.

De toute façon meme les framework basés sur MongoDB utilisent des relations comme ça.

Et c'est mauvais. Un framework NoSQL qui m'incite à faire des relations, personnellement j'ai très envie de le jeter à la poubelle en le voyant. Mongo (je dis "Mongo" mais c'est aussi vrai pour RavenDB, pour CouchDB, et même pour des key-value stores comme Redis, qui ne sont en fait que des bases orienté-documents modulo la sémantique du document), contrairement à ce que la mode dicte, n'est PAS généraliste. Si on a besoin de faire des relations dans une base Mongo, c'est qu'on s'est trompé et qu'on aurait mieux fait de partir sur du PostgreSQL. J'exagère évidemment, car au cours du développement dans certains cas ça peut être plus pratique de coller une relation là où on ne l'attendait pas au moment de la modélisation, mais si dès la modélisation tu te dis que tu veux mettre une relation, c'est que tu fonces dans le mur avec Mongo.

Tout ce que je dis c'est pas du vent, c'est du vécu, et je suis pas le seul à le dire. Pour un exemple grandeur nature je te renvoie vers le retour d'expérience de Diaspora sur Mongo : http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ qui dit globalement ce que je viens de dire mais avec du concret.

Et pour revenir sur ce que j'ai dit précédemment, les bases NoSQL n'invitent PAS à dénormaliser des données normalisées, elles permettent de travailler sur des données dénormalisées de base. C'est LA grosse idée fausse reçue quand on parle de NoSQL. En gros si l'idée c'est "on va faire du NoSQL parce que comme ça on aura pas à se faire chier à modéliser nos données" c'est mal parti. On choisit du NoSQL parce qu'on ne peut pas ou parce qu'on ne sait pas normaliser des données. C'est pour ça que sur un projet bien fait on trouvera généralement en parallèle une base relationnelle et une base NoSQL (ou éventuellement une base PostgreSQL sur laquelle on utilisera les champs de type JSON)

(à noter que je suis assez tranché dans mon avis car pour commencer à triturer le relationnel vs NoSQL c'est mieux de l'être, mais dans la pratique c'est pas le cas, comme le dit lisarael le "peu relationnel" ça existe, et dans des cas comme ça effectivement on va introduire quelques relations dans du NoSQL, mais ça reste pas idéal)