5 Document-oriented Data Modeling
In this chapter:
- What is document-oriented modeling
- How to approach modeling for RavenDB applications
- Working with document references
- Various considerations that influence modeling approaches
Communication is key, and language is at the heart of any communication. Two people not speaking the same language will not understand each other, and while in many scenarios that can be just fine, think about trying to organize a large event without having one language being spoken by all the organizers. That will not end up nicely.
This is pretty much the same with software. Running a software product in isolation is easy. Once it needs to communicate with the outside world, things get more complicated as there needs to be an agreement on protocols, language, formats and so on, otherwise it just won’t work.
One important example of such commonly required communication is when an application needs to persist data. To be able to this correctly, it needs to talk with some database engine. This discussion needs to be made in a language both ends can fully understand. A glitch in understanding the communication from either side may result in data corruption, and this is something we don’t want to see happening.
Equally important is the amount of chatter that happens between the application and the database. The less chatter that happens, the more to-the-point the discussion is, the more performant the application can be.