2012-09-10 7 views
2

J'ai récemment commencé à regarder RavenDB, et j'ai essayé de voir si cela convient à certains de nos projets. Cependant, j'ai rencontré quelques questions concernant la «bonne» façon de modéliser une structure de données simple. Je vais essayer de le décrire:Modélisation de données RavenDB

  • Il y a 3 types d'objets: Guides, Catégories et Liens
  • A "root" Guide peut contenir 0 ou plus sous guides
  • Guide peut contenir 0 ou plus Catégories
  • A Catégorie peut contenir 0 ou plus Liens

visuellement la structure serait:

  • root-guides (0 ou plus)
    • Sous-guides (0 ou plus)
      • Catégories (0 ou plus)
        • Liens (0 ou plus)
    • Catégories (0 ou plus)
      • Liens (0 ou plus)

Dans les données réelles, il est environ 20 guides racines et environ 3-5 sous-guides sous chaque guide racine. Sous chaque guide (les deux sous-guides et sous-guides), il y a 15-25 catégories. Et sous chaque catégorie il y a entre 5 et 20 liens.

Ma première pensée devait ce modèle comme celui-ci (modèle simplifié):

Guide 
--------------- 
Id 
ParentGuideId 
Title 

Category 
--------------- 
Id 
GuideId 
Title 

Link 
--------------- 
Id 
CategoryId 
Title 

C'est à peu près le modèle relationnel et je me rends compte que cela pourrait ne pas être la bonne façon de modéliser les données dans RavenDB. Alors, quelle est l'alternative? Le problème, je suppose, est que je ne veux pas stocker la hiérarchie comme ceci:

Guide 
--------------- 
Id 
Title 
SubGuides 
Categories 

SubGuide 
--------------- 
Title 
Categories 

Category 
--------------- 
Title 
Links 

Link 
--------------- 
Title 

, car elle entraîne des documents avec potentiellement des milliers de sous-objets. Veuillez garder à l'esprit que le modèle ci-dessus est simplifié. En réalité, il y a beaucoup plus de données sur chaque type, donc les 20 documents du guide racine dans RavenDB seraient énormes si nous allions avec ce modèle.

Y a-t-il des alternatives? Peut-être que ce sont mes années de mauvaises relations relationnelles, mais peut-être que ce scénario ne convient tout simplement pas à RavenDB et à SQL?

EDIT (ajouté requêtes de base)

L'accès aux données est assez simple. J'ai les exigences suivantes:

  1. Sélectionnez une liste de guides-racines avec tous les sous-guides.
  2. Pour un guide spécifique (racine ou sous), obtenez tous les sous-guides (si racine), les catégories et les liens.

C'est essentiellement tout ce dont j'ai besoin. Cependant, l'une des raisons pour évaluer RavenDB ou similaire, était d'ajouter des capacités de recherche. Comme je l'ai déjà mentionné, il y a plus d'informations sur les liens, les catégories et les guides, tels que la description, les balises, etc., donc ce serait bien de pouvoir faire des recherches sur l'ensemble de ces éléments.

+2

La bonne façon de modéliser dépend beaucoup de la manière dont vous envisagez d'y accéder et de la manière dont vous voulez organiser vos frontières transactionnelles en définissant vos agrégats. Il serait beaucoup plus facile de vous aider si j'avais une idée de la façon dont votre application va accéder à ces données. –

+0

J'ai ajouté les deux requêtes essentielles que nous utilisons aujourd'hui. :) – JohannesH

Répondre

2

Je manipulerais les choses pour que Guide soit un document. Les catégories et les liens sont intégrés dans ce document.

Un Guide peut avoir une collection de sous-guides.

La première requête consiste à interroger tous les guides avec leurs sous-marins. Vous faites cela comme ceci:

session.Query<Guide>().Include(x=>x.SubGuides).Where(x=>x.Parent == null).ToList(); 

Cela vous donnera tout cela dans une requête serveur.

session.Include<Guide>(x=>x.SubGuides).Load("guides/123") 

Cela vous donnera un guide avec tous ses sous-guides.

+0

Merci Ayende. Serait-il possible de rechercher des liens en utilisant un index de recherche si je choisis cette structure? Je suppose que l'index trouverait simplement le document guide, ou est-ce que je me trompe? – JohannesH

Questions connexes