No-SQL Database Design for restaurant app
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.