5

I’m creating a document model of my entities to store in a Document Database (RavenDB). The domain I’m modeling revolves around Incidents. An incident has a source, a priority, a category, a level of impact and many other classification attributes. In a RDBMS, I’d have an Incident table with Foreign Keys to the Priorities table, the Categories tables, the Impacts tables etc but I don't know how to handle that in a document database (that is my first Doc BD).

I have two types of reference data:

  1. Simple lookup values: Countries, States, Sources, Languages. Attributes: They only have a Name but this is a multilingual system so there is name for each language. Supported operations: create, delete, rename, deactivate and merge.

  2. Complex reference data: Same as the Simple Lookups plus: Several of those have many fields and have business rules and validation rules of their own. For instance two Priorities cannot have the same Rank value. Some have a more complex structure, for instance Categories are composed of Subcategories.

How should I model those as (or as part of) documents?

PS: Links to Document Database Modeling Guidelines would be appreciated as well

Sylvain
  • 19,099
  • 23
  • 96
  • 145
  • I guess as for `categories` and `subcategories`, it depends on whether you need to call the `subcategories` directly. The general idea of document-oriented db would be to store the subcategories as a dictionary (as tree). But then you can only read the first level directly, rest has to be done with map-reduce.As for the multilingual system: Again this might be a case for dictionaries, this time with the language-code (`de_DE` or `de`) as key. But not sure if that’s the best solution, maybe you are more into doc-db than me. – aufziehvogel Jun 19 '12 at 19:50
  • What I just found, here Zuelke shows how to get reference data via map-reduce (p 41 following). Maybe that’s also interesting: http://www.slideshare.net/Wombert/an-introduction-to-couchdb-ipc11se-20110601 – aufziehvogel Jun 19 '12 at 20:14

1 Answers1

3

Handling relationships is very different for a document database to a SQL database. RavenDB documentation discusses this here. For things that rarely, if ever, change, you should use denormalized refences.

Further, there is a good discussion about modelling reference data by the main RavenDB author, here. You can expand this example to include a dictionary of abbreviations/names per locale pretty easily. An example of this, here.

To answer your specific questions:

  1. You can store a key for each Country/State/etc and then retrieve the locale-specific version using this key, by loading the whole reference data document and performing an in-memory lookup.
  2. Denormalized references would be a good suit for categories. You can include the Name and/or parent category if it has to be displayed. It sounds like the entity itself is small so you may as well store the whole thing (and don't need to denormalize it). It's ok to replicate it - it's cheaper to process this way and it won't change, or at least not often (and if it does you can use patching to update it). The same applies for your other entities. As far as I can see, business rules have nothing to do with the database, other than you must be able to run the appropriate queries to enforce them.

Update: Here's a post that describes how to deal with a tree structure in Raven.

georgiosd
  • 3,038
  • 3
  • 39
  • 51