I've been working with SQL databases all my life and I am now trying to get into the NoSQL world. I am a looking for a piece of advice on whats the best practice in order to achieve this.
Suppose I have a table that contains all the meals on the menu and another with the the waiters information. I want to create a third table for the orders. What is the best practice to archive this using a NoSQL database?
In traditional SQL I would have made a table called Orders with an ID and foreign key pointing the waiter id. And I would have created another table relating meals id with order id.
What is the recommend approach to do this in a NoSQL database?
You must have into consideration there will be a "client" running in the kitchen showing the orders.
If it's any relevant I will use parse.com as backend.
Greetings!
Best Answer
As NoSQL databases typically do not support joins, they expect you to store the data in de-normalized form. (So, throw the codd normalization rule book away. Just kidding). In this case, the thrid table better have the values duplicated something like (orderid, ordertime, [itemnames], waitername, orderserviced yes/no, servicetime, ...). itemnames can be a list type which is supported by many NoSQL databases. Not all but some databases support secondary index queries. You can query for all the orders where orderserviced=no to get all the open orders.
You may still do what is similar to joins at application level if one of the table is small and can be cached by the application. You can do a hash look up of the id and get the actual value.
In general, you should be conscious that NoSQL databases come with a limited functionality. But they give more flexibility in-terms of the schema and generally tuned for high-volume applications and clustering/HA in mind.