Databases
StackOverflow2013
Postsdbo
POHow would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?
    primarykey
    data
    text
    <p>Document oriented databases (particularly RavenDB) are really intriguing me, and I'm wanting to play around with them a bit. However as someone who is very used to relational mapping, I was trying to think of how to model data correctly in a document database.</p> <p>Say I have a CRM with the following entities in my C# application (leaving out unneeded properties):</p> <pre><code>public class Company { public int Id { get; set; } public IList&lt;Contact&gt; Contacts { get; set; } public IList&lt;Task&gt; Tasks { get; set; } } public class Contact { public int Id { get; set; } public Company Company { get; set; } public IList&lt;Task&gt; Tasks { get; set; } } public class Task { public int Id { get; set; } public Company Company { get; set; } public Contact Contact { get; set; } } </code></pre> <p>I was thinking of putting this all in a <code>Company</code> document, as contacts and tasks do not have a purpose out side of companies, and most of the time query for a task or contacts will also show information about the associated company. </p> <p>The issue comes with <code>Task</code> entities. Say the business requires that a task is ALWAYS associated with a company but optionally also associated with a task.</p> <p>In a relational model this is easy, as you just have a <code>Tasks</code> table and have the <code>Company.Tasks</code> relate to all tasks for the company, while <code>Contact.Tasks</code> only show the tasks for the specific Task. </p> <p>For modeling this in a document database, I thought of the following three ideas:</p> <ol> <li><p>Model Tasks as a separate document. This seems kind of anti-document db as most of the time you look at a company or contact you will want to see the list of tasks, thus having to perform joins over documents a lot.</p></li> <li><p>Keep tasks that are not associated with a contact in the <code>Company.Tasks</code> list and put tasks assocaited with a contact in the list for each individual contacts. This unfortunately means that if you want to see all tasks for a company (which will probably be a lot) you have to combine all tasks for the company with all tasks for each individual contact. I also see this being complicated when you want to disassociate a task from a contact, as you have to move it from the contact to the company</p></li> <li><p>Keep all tasks in the <code>Company.Tasks</code> list, and each contact has a list of id values for tasks it is associated with. This seems like a good approach except for having to manually take id values and having to make a sub-list of <code>Task</code> entities for a contact.</p></li> </ol> <p>What is the recommended way to model this data in a document oriented database?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USKallDrexx
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POHow would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?
      1. USccellar
      1. VTFavorite
    3. VO
      singulars
      1. POHow would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload