I have an application that I'm moving from a SQL Server database to a RavenDB Document Database. The first order of business is updating the data model. Document data modeling and relational data modeling are totally different.
Below is part of the data model. It contains the relationship between Camps & Programs. For this application, a camp can have multiple programs. A program is a specific type of activity program for a given age or grade. For example, a sports summer camp may have a baseball program for 2nd to 4th grade. In a relational database this concept is actually fairly complex to model.
Entity Relationship Model
While the relational database model is fairly complex and will require lots of joins to access, the corresponding document data model is nice and simple.
Document Data Model
There are two documents. The Camp document contains a collections of references to the related Program document. While you could model this as one big document, the application allows users to search at the Program level & schedules Campers at the program level. This is why the Program document is separate.
The JSON for a Camp looks like the following:
"Name": "High School Sports Camp",
"Name": "Kathleen Smith",
"Name": "Baseball Camp - Session 1"
"Name": "Baseball Camp - Session 2"
And the JSON for a related Program:
"CampName": "High School Sports Camp",
"Name": "Baseball Camp - Session 2",
The nice thing about document models is you can also denormalize data to improve access. In this example, I've included the Camp Name in the Program Document and the Program Name in the Camp document. This saves additional document loads to get basic information.
Hopefully this gives you some insight into document data modeling. It is key to building an efficient, easy to develop applications.
My new book, RavenDB High Performance, covers this topic in depth and much more. I encourage you to check it out if you are building document databases.