2011-11-26 3 views
3

Je construis une application sur node.js qui a des utilisateurs et des produits dans une relation plusieurs-à-plusieurs (un utilisateur a beaucoup de produits et le même produit peut appartenir à plusieurs utilisateurs). Chaque utilisateur a également des informations de localisation. La plupart du temps, j'ai besoin de faire beaucoup d'écritures lors de la première visite de l'utilisateur (quelques-unes sur les visites suivantes) et ensuite je dois faire correspondre les utilisateurs qui, par exemple, ont le plus de produits en commun. mêmes produits en commun. Je peux aussi vouloir faire correspondre les utilisateurs par emplacement (ou les trier par emplacement correspondant)MongoDb est-il adapté à mon application?

J'utilise postgres en ce moment mais je pense que je ferais mieux de faire mongo à long terme. Le problème est que je n'ai jamais travaillé sur NOSQL DB (aucune crainte;))

La question est, est le "schéma" suivant adapté à la décrite ci-dessus?

[user]{ 
_id 
name 
age 
[location]{ 
      streep 
      town 
      country 
      } 
} 

[products]{ 
_id 
name 
color 
[users]{ 
     user_id_1 
     user_id_2 
     user_id_3 
     } 
} 

Je pense, en raison des exigences, que je suis meilleur de cette façon qu'avec l'incorporation. Ai-je raison? Pensez-vous que je devrais stocker le products_id dans le document de l'utilisateur?

Merci!

+0

Juste curieux, pourquoi pensez-vous que le mongo est meilleur? Avez-vous des problèmes pour utiliser votre base de données actuelle avec vos besoins? – JohnP

+0

Eh bien pour une performance que j'entends être beaucoup mieux (vu des graphismes prometteurs) et j'ai quelques problèmes avec l'implémentation de postgres que j'utilise pour node.js, ce qui me frustre un peu. Pensez-vous que je devrais rester avec postgres? Merci!! – jribeiro

+1

Je me demandais juste pourquoi vous étiez en train de faire le changement. Le pilote mongo pour node est assez bon et il y a beaucoup de frameworks donc pas de soucis là-dessus. Mais si vous travaillez avec des données jointes, cela ne sera pas aussi clair que sur une base de données relationnelle. Cela dépend de la duplication des données que vous êtes prêt à accepter. La normalisation prend un peu un coup sur mongodb parce que les cas d'utilisation sont un peu différents. – JohnP

Répondre

3

Vos données me semblent assez relationnelles. Je ne verrais pas un grand avantage pour les solutions MongoDB ou NoSQL. Ils fonctionnent bien pour les solutions documentaires qui ne sont pas relationnelles.

J'obtiendrais des données si vous rencontrez des problèmes de mise à l'échelle ou de performances. Ne présumez pas de solution tant que vous ne connaissez pas la cause première. Cela pourrait être node.js - qui sait? Some people s'en foutent beaucoup.

+0

Il y a quelques très bons points là-dedans mais, pour moi, l'avantage de node.js est de travailler sur un langage accepté comme javascript c'est la simplicité à utiliser. La façon dont je le vois c'est une sorte de coût/efficacité du serveur par rapport à votre temps et à votre efficacité. Cela étant dit, il est définitivement agréable d'être informé et préparé lorsque le nœud (éventuellement) mord, mais en ce moment la performance db est le principal problème. Environ 2000 insertions moyennes lors de la première visite et seulement après ce nœud peut faire sa magie (cela va un peu contre le principe du nœud mais je pense avoir une solution) Merci !! – jribeiro

+0

ouais désolé pour l'erreur d'orthographe ... – jribeiro

Questions connexes