NoSQL - Database Design: How To Properly Design Or Represent an Association In A NoSQL Database Schema?

Question

I am designing a database for a Car Wash app I am working on and I would like to know couple things. The database will either be on MongoDB or Firebase/Firestore. In the meantime I spent a lot of time conceptualizing the database and this is what I came up with:

I would like to point out that eventhough this design inludes Primary Keys(PK) and Foreign Keys (FK) they won't be represented as such when I actually build the database. Instead they will just be references to external documents/tables. So here are my questions:

1. Do you guys think the database in its simplest form was designed correctly? If not What did I do wrong?
2. Do you guys think the relation between OrderDetails, Service, Addons and Order are properly constructed?
3. Should the Business be connected to Order instead of Service?

4. When actually building the database (MongoDB/Firebase/ Any NoSQL) how should I represent OrderDetails? As an embedded document inside Order or vice-versa. I am a little confused and this my attempt; Please let me know what you think.

   let order = {
       'order_id':'jxde5retvggfffgggv',
       'customer_id':'hdksjf456jvvhgkk',
       'date':'05-14-1985 13:00',
       'total_amount':'1500',
       'order_detail':[{
           'order_id':'jxde5retvggfffgggv',
           'service_id':'ope4fghgi9nnsgu',
           'addon_id': '4fhtyucfjfigpq9fh',
           'quantity': 20
       },
       {
           'order_id':'jxde5retvggfffgggv',
           'service_id':'7reaolmdgfirgt8om',
           'addon_id': 'sd2aqerthnnmgdpmb',
           'quantity': 35
       }]
   }
   

[UPDATE - OCTOBER 5 2019] DATABASE DESIGN

I just realized that the vehicle that needs to be washed should be part of the order, So I changed the design a little bit to reflect that. By doing so, I still make sure that the customer is still accessible from the order, because customer_id is attached to the vehicle. Please let me know what you think.

Answer 1

The answers to your first three questions can't be given without knowing your precise functional requirements and the semantics of your entities.

1. In general, your design looks well. However, I didn't understand the semantics of Business, Service and Wash Type well enough to be sure. Your next two questions show that there might be problems in that part of the model.

2. As Service contains wash_type_id as an FK, probably the one-to-many direction in the diagram should be the other way round. I don't quite get the meaning of that relationship. As the Service contains a description and a unit price, I guess it is the offer made to customers. But why do (probably) many Services point to the same Wash Type? Possibly it makes sense to separate those two, but without knowing your business requirements it is difficult to understand this.

3. I'm not sure about the semantics of the Business entity. Do different instances refer to different companies offering car wash services? If so, the answer should probably be no, because different companies are unlikely to share the same service offers. If, however, Business just means a branch of the same company, then maybe the service offers are the same for all Business instances, and Business might connect to Order. Depends on your requirements.

4. I'm not familiar with Mongo and Firebase, but I know Couchbase. The general design consideration for nesting objects is that you can only refer to the top-level object from other objects by pointing to its id. So the solution you suggest is okay as long as you only refer to Orders from other objects, but never to specific OrderDetails. That should be okay for lots of use cases. It will, however, make it difficult to make an evaluation of all OrderDetails that used a specific Service - finding those means to open all Orders to find out whether some of their details refer to that Service. The vice-versa way makes no sense at all. The OrderDetail is contained in the Order, not the other way round. Making OrderDetail the root and including Order in it would mean to repeat the order data redundantly for each OrderDetail instance. If you want to make OrderDetail a first class object, however, you might completely separate it from Order.