At our company, I have been given the task to develop a Mobile Application (iOS, Android and in the future, maybe Windows). Given those devices, it's likely that we'll have a high number of installations spread over all those devices.
Off course, for a mobile application it's very important to be responsive, so therefore we've decided to move from a classic SQL Environment (SQL Server) to a No-Sql (MongoDB) solution.
We've chosen this approach because the platform is highly scaleable which can come in handy in the future.
You need to know that I'm totally new to the No-Sql story, so don't blame me on eventual dumb questions, I'm here to learn the best practices.
Let's start by looking at the data that I do need to import.
The application which our company is developing is an application to browse through a catalogue of articles which can potentially be purchased. There's a specific hierarchy of those articles which I'll try to explain in the image below:
To explain the image above a bit in words:
1 have a classification on the root level (for example - kitchen articles), under which I can have (not mandatory) another classification (for example knives). This goes for 4 levels deep.
Under each classification I can have an Article Group, (for example: knife, steel, black), and then under each article group, I always have some articles (for example: Blade: 20cm, Blade: 22cm, Blade 24cm).
To give you an idea about the knife, see the following Json (I'll try to explain it the best possible way):
{
"Name":"Kitchen",
"Classifications":[
{
"Name":"Knives",
"Article Groups":[
{
"Name":"Knive Steel Black",
"Articles":[
{
"ArticleGTIN":"684351654984"
}
]
}
]
}
]
}
This is roughly how the data is stuctured. One more thing which is very important is that articles can have multiple properties.
Below is a snippet of just an article with some properties on it:
{
"ArticleGTIN":"984651164",
"Properties":[
{
"Name":"Length",
"Value":"20cm",
},
{
"Name":"Hardness",
"Value":"1",
}
]
}
Now, for the application, I need to be able through the catalogue, thus:
- Seeing all the classifications on the root level.
- If a classification is selected, see all child classifications.
- For each an every classification, I need to be able to view the article groups.
- For each an every article group, I need to be able to view the articles.
- Most important: I need to be able to filter at all the given properties for an example. By this I mean that I must be able to say: find me all knives with a hardness >= 2 and where the Length is at least 10cm (I think you get the point). It's kind of a filter like the search on Amazon:
The problem which I'm facing is that I don't know exactely how I should store my data to keep my application as performant as possible. I do have a couple of options in mind:
One big collection named "Classifications" in which everything is stored. So, one 'parent' node and all child nodes under it (see diagram above).
Many small collection with each entry in a collection referring to another colletion, for example, a collection with classifications and then another collection with article groups. Each article group does hold a reference (based on an 'Id' field with the correct classification).
Create collections that matches the data exposed on the application. For example the search, I can create a collection with only articles and their given properties.
...
I hope that someone can give an answer on what's best suited here.
One more thing on which I'm looking for answer. To use the application, you need to be authenticated. For that I was using Microsoft Authentication Framework (Entity Framework, SQL Server). Is it best to keep this, and thus mixing SQL Server and MongoDB or is it better to store everything in a single database technology?
Note: I'm looking for facts and best practices. Please include a why or why-not in your answer so that I can make the best decesion based on the given answers.
