Geo Location & Spatial Searches with RavenDB–Part VI–Database Modeling
If you had sharp eyes, you might have noticed that in this code, I am actually using two different sessions:
We have the GeoSession, and we have the RavenSession.
The GeoSession is actually pointed at a different database, and it is a read only. In fact, here is how we use this:
As you can see, we create this on as needed basis, and we only dispose it, we never actually call SaveChanges().
So, those are the technical details, but what is the reasoning behind this?
Well, it is actually pretty simple. The GeoIP dataset is about 600 MB in size, and mostly it is about... well, geo location stuff. It is a very nice feature, but it is a self contained one, and not something that I really care for putting inside my app database. Instead, I have decided to go another way, and use a separate database.
That means that we have separation, at the data layer, between the different databases. It makes sense, about the only thing that we need from the GeoIP dataset is the ability to handle queries, and that is expressed only via GetLocationByIp, nothing more.
I don’t see a reason to make the app database bigger and more complex, or to have to support updates to the GeoIP dataset inside the app. This is a totally separate service. And having this in a separate database make it much easier to use this the next time that I want to use geo location. And it simplify my life right now with regards to maintaining and working with my current app.
In fact, we could have taken it even further, and not use RavenDB access to this at all. We can use REST calls to get the data out directly. We have chosen to still use the RavenDB Client, I’ll discuss exactly why we chose not to do that.