1

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:

enter image description here

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:

enter image description here

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.

  • Looks like relation data to me. You want to treat it relationally. How many articles could you have? You are sure SQL won't scale to your needs? – paparazzo Aug 1 '15 at 9:36
  • 3
    Agree with @Frisbee - your data looks like an ideal fit for SQL, but the main benefits of NoSQL are when you have data that doesn't normalise easily - Nosql databases handle denormalized data (in a variety of forms) better than SQL can. Looks like a premature optimization to me. – Jules Aug 1 '15 at 10:01
  • The idea why we switched to NoSQL is because of the speed and scaleability. I will need to quite some joins on tables for a search query, and I need the response to be almost direct. – Complexity Aug 1 '15 at 11:05
  • 2
    So you're building a multi-level ecommerce application. That's nothing new - we've been doing it since the 90s, using SQL. Written well, SQL is spooky fast and scales probably better than you need. You should write some test applications and measure the performance of each. – Dan Pichelman Aug 1 '15 at 14:49
  • 2
    because of the speed and scaleability it is wrong that NoSQL scales better than SQL. NoSQL and SQL just have different fields of use where they scale well and others where they scale worse, in your case however, NoSQL scales really bad since your data is relational and there are no joins in NoSQL as you know them for SQL, so ultimately you need to fetch a lot of data one by one which you would've gotten in a single JOIN statement with relationale databases. – tkausl Aug 1 '15 at 15:56
-1
article: {
    articleGTIN: value,
    properties: [
        { name: value, value: value }, 
        { name: value, value: value }
    ],
    articleGroups: value,
    classification: value
}

NoSQL databases is also called document database, that means the entity of the database should be a document like structure.

Think of your articles as document, a paper you hav in front of you and everything else is META data.

Use the global trade item as the unique key and if you need more multiple classifications or articleGroupd per article, embedd them, ie. treat them as I suggest to use the properties, as an array of objects.

  • 1
    There are many more NoSQL types than document databases. Wikipedia – user40980 Sep 8 '15 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.