How to work with NESTED Parent, child, and grandchild and multiple related tables

[Muhammad_Salooj]

What's the best way to set up nested child tables and nested grand child tables.

The nested grandchild table will need to inherit a link to or at least extract data from the:

(Parent table) VEHICLES  - which has a child table:

(Child table) WORKSHOP PROJECT'S TABLE:

and WORKSHOP PROJECTS table has a child table:

(which would need to be the grandchild of VEHICLES TABLE 😞

called (grandchild) TASKS TABLE. 

Also,.

For the same app, I have  VEHICLES TABLE and then I also have a SOLD VEHICLES TABLE and A table for VEHICLES NOT IN VEHICLE TABLE and not in VEHICLES SOLD  - I need to be able to create projects and  tasks for all these types but show them on the same dashboard view 

(App is for a dealership) 

@MultiTech @Aleksi @CJ_QREW 

[dbaum]

---

@Muhammad_Salooj wrote:

What's the best way to set up nested child tables and nested grand child tables.

---

Have you created Ref columns in the child and grandchild tables as explained in References between tables - AppSheet Help

---

@Muhammad_Salooj wrote:

For the same app, I have  VEHICLES TABLE and then I also have a SOLD VEHICLES TABLE and A table for VEHICLES NOT IN VEHICLE TABLE and not in VEHICLES SOLD  - I need to be able to create projects and  tasks for all these types but show them on the same dashboard view 

---

You can certainly create views for each of those tables and include all the views in a single dashboard view. Consider also collapsing all your vehicle tables into a single table and then distinguish each vehicle's status via a column value like "Sold". You could define slices with criteria that correspond to your currently separate tables and use those slices just like you're using the tables now--including making a separate view for each slice to include in a single dashboard view.

[Muhammad_Salooj]

Would It be okay to reference the same VEHICLE TABLE - Using a self-referencing relationship ( recursive relationship)...? 

USE CASE: When selling a vehicle, sometimes the customer has a vehicle he is trading in. That traded in vehicle needs to be recorded against the sold vehicle.

Actually,

I'm thinking I'd need an intermediary join table because sometimes the customer trades in multiple vehicles against one or more vehicles that he is purchasing..

[dbaum]

Here's a data structure suggested by your description of your use case.

• Table 1: Vehicles
  • Vehicle ID
  • Etc.
• Table 2: Vehicle Sales
  • Sale ID
  • Vehicle ID (for vehicle sold - Ref type column based on Vehicles table)
  • Etc.
• Table 3: Vehicle Trade-ins
  • Trade-in ID
  • Sale ID (for parent sale - Ref type column based on Sales table)
  • Vehicle ID (for vehicle traded-in - Ref type column based on Vehicles table)
  • Etc.

[Muhammad_Salooj]

Okay  Great, so this is how it should be set-up , correct? :

The Vehicles table will be the master table, 

The Vehicle Sales table will be the other table, 

and the Vehicle Trade-ins table will be an intermediary table from which I'll be able to reference but also add the Traded-in vehicle into stock into the master table via the Ref to the Vehicles Master table.