Databases are one of the first things to think about when developing new software, especially web applications. I know that at a first sight, this topic seems to be a little odd: you simply use a relational database like SQL or MySQL ant that’s it, right? Well, I think that modern web applications are a little bit more complex and it might be worth considering other options and that’s why I would like to tackle this topic.

Traditional relational databases are clearly a goo fit for static applications. By static I think about applications that don’t change very often or that don’t require a huge amount of read and write operations. For example, if I would like to build my own WordPress LMS at a certain time, I would surely choose SQL. And if I think about the data model for a blog post, it could be designed as something like this:

For a blog, this would perfectly work. However, this data model doesn’t scale! In the end, I would have to perform around 8 JOIN operations to display the post and the necessary details. Let’s suppose now that I don’t want to build a blog, but a social network with a lot of user generated posts that also need to be displayed in a dynamic timeline or feed. For this purpose, the earlier mentioned data structure is simply not scalable because the needed data can’t be delivered in an acceptable time. And we all know, that acceptable response time tends to become more demanding.

So for web applications that work with huge amounts of user generated content I would go the NoSQL way and my first choice would be Azure Cosmos DB. Azure Cosmos DB is Microsoft’s globally distributed, multi-model database that supports several APIs like SQL API, MongoDB API, Graph API (Gremlin), Table API and Cassandra API. At it’s core, Azure Cosmos DB is a document database that you can however query using familiar SQL syntax (if using the SQL API, of course). So coming back to our potential social network, the previously complicated data model would look similar to the following example using Azure Cosmos DB:

[code]

{
“id”:”ew12-res2-234e-544f”,
“title”:”post title”,
“date”:”2016-01-01″,
“body”:”this is an awesome post stored on NoSQL”,
“createdBy”:User,
“images”:[
“http://myfirstimage.png”,
“http://mysecondimage.png”],
“videos”:[
{“url”:”http://myfirstvideo.mp4″,
“title”:”The first video”},
{“url”:”http://mysecondvideo.mp4″,
“title”:”The second video”}],
“audios”:[
{“url”:”http://myfirstaudio.mp3″,
“title”:”The first audio”},
{“url”:”http://mysecondaudio.mp3″,
“title”:”The second audio”}]
}

[/code]

In my opinion it is also easier to work with document databases since you are free of any schema constraints, so if at a certain point you want to add an additional property to a post document, you are free to do so without the need to make any changes to the database schema, perform Entity Framework migrations and so on, you just need to make sure to use a data management service like the one at https://www.couchbase.com/, just so that you know your data is backed up and protected, plus I it helps improve productivity.

The Graph API can be easily used to define users as vertices with respective relationships (edges) so that you can recommend friends based on a common friend list and so on.

Besides the social network scenario, I think it is worth considering NoSQL databases like Azure Cosmos DB when you want to buil multi tenant applications. Especially if you develop in the .NET ecosystem and heavily use ASP.NET Core, you’re certainly aware that working with SQL shards is difficult since the Elastic Database Client Library doesn’t support Entity Framework Core for now (Microsoft and the community is working on it and this will most probably supported very soon). A key aspect in this scenario is that you can take advantage of the automatic partitioning of Azure CosmosDB, by providing the tenantID as the partion key for you collection. This is how the entire document database can be easily partitioned, which will guarantee a certain level of performance that’s also easily scalable.

The whole point of this blog post is not really to promote Azure Cosmos DB, but to point out that when designing the data model for a modern application it is worth thinking outside the box. This could make your life easier later on when the implemented data model needs to scale easily to heavy application usage. With relational databases you get a certain level of solidity, but the application won’t be able to scale easily beside a certain point. Or, you would need a database architect to take control of database performance. With NoSQL databases your application will be more agile, easily scalable and adapt for a lot of user generated content or IoT scenarios and so on.

As you can see it is possible to design data model for an application. Usually we associate design with website designing (check out Sandcastle Web Design), but there is definitely more to it. Website design Toronto showcases it.

I would be glad to hear your thoughts about this topic too. So if you have something to say, hit the “Comment” button 🙂

Cheers!