2010-06-20 18 views
4

J'ai examiné des bases de données de documents, en particulier RavenDb, et tous les exemples sont clairs et compréhensibles. Je ne trouve pas d'exemple où nous ne savons pas à l'avance combien de niveaux a une structure donnée. À titre d'exemple, comment voulez-vous persister un arbre généalogique donné la classe suivante:Comment modéliser des structures telles que des arbres généalogiques dans des bases de données de documents

public class Person{ 
    public string Name {get;set;} 

    public Person Parent {get;set;} 
    public Person[] Children {get;set;} 
} 

Dans la plupart des exemples que je l'ai vu, chercher la racine globale et faire dans un document. Ce n'est pas si évident ici quelle est la racine et la limite globales.

+0

Rune, s'il vous plaît marquer une réponse comme la réponse acceptée, si possible. – Peter

Répondre

2

Je suppose que pour RavenDB, vous devriez garder le Ids dans votre objet:

public class Person { 
    public string Name { get; set; } 
    public string ParentId { get; set; } 
    public string[] ChildrenIds { get; set; } 
} 

Vérifiez cette page, surtout en bas, pour plus d'informations: http://ravendb.net/documentation/docs-document-design

+0

Bon, c'était aussi mon premier penchant. Mais comme il le dit aussi, cela va en quelque sorte à l'encontre des idées de base derrière les bases de données documentaires. L'interrogation des données modélisées de cette manière pourrait être très lente par rapport à des documents plus agrégés. Ce que je cherche, ce sont des stratégies moins "évidentes". –

+0

J'ai posté ceci dans le groupe RavenDb Google (http://groups.google.com/group/ravendb/browse_thread/thread/8a75de45916a8593). Je pense que vous devriez obtenir une réponse sous peu. – Peter

+0

Je suppose que cela dépend en partie de ce que vous considérez comme votre «racine agrégée». Par exemple, l'opération commune arrache-t-elle une personne en particulier et tous ses descendants à un certain niveau, c'est-à-dire 3 générations? Si oui, vous pouvez stocker cela comme votre document. Le principe général de RavenDB est que les écritures coûtent cher, mais les lectures sont bon marché. Donc, un document devrait se suffire à lui-même. –

3

Ayende vient de publier un blog post qui répond à cette question.

+0

Je viens de le voir dans RSS-feed :) La solution de dénormalisation des données vous oblige à savoir exactement ce dont vous avez besoin partout dans votre interface utilisateur, mais je suppose que pour la plupart des scénarios, c'est la technique que j'utiliserais. –

+0

Ouais bon point, mais je pense que comprendre cette partie est le principal différent de RavenBD v RDMS. De plus, vous pouvez utiliser des index pour vous asseoir sur les documents afin de sortir d'autres "vues". –

+1

Pour faciliter les mises à jour, vous pouvez utiliser des opérations basées sur des ensembles (voir http://groups.google.com/group/ravendb/browse_thread/thread/d898694f321586ea). Vous pouvez donc utiliser un index pour mettre à jour les documents directement, plutôt que de les extraire. à partir du serveur, modifierung et les poster. Aussi vous pouvez PATCH documents, voir http://www.ravendb.net/documentation/docs-http-api-patch. –