Hi everyone,
I am creating a trucking logistics app for my company. The goal is for drivers to fill a trip form every time they complete a delivery. Each submission includes date,Trip UID, Driver ID, tonnage, destination, and a photo of the receipt.
I need a separate table to automatically calculate:
Daily total trips
Daily total tonnage
Monthly total trips
Monthly total tonnage
Drivers must only see their own trips
Could someone explain in detail how to structure the data in Glide, including how each column should be set up and connected?
If you have suggestions on the best data structure, formulas, or Glide features to use, Iβd really appreciate your advice. My goal is to make this app efficient and scalable, so any improvement tips are welcome. Thanks in advance!
A good approach is to keep all delivery records in a single Trips table, and then use relations + rollups for your totals. You donβt need a second table for the calculations unless you move into very large datasets.
1. Trips Table (main data source)
|Column|Type|Purpose|
| β | β | β |
|Trip UID|Unique ID|Generate automatically|
|Driver ID|User reference|Email/userID of the driver|
|Date|Date/Time|Delivery timestamp|
|Tonnage|Number|Load delivered|
|Destination|Text|Delivery location|
|Receipt|File/Image|Photo of signed receipt|
β
2. Security (Drivers see ONLY their own trips)
Enable Row Owners on the Driver ID column.
This ensures:
Drivers only see their own rows
Data is protected at the database level, not just filtered visually
Required if you are dealing with business/real-world trip data
β
3. Daily / Monthly Totals
Inside the Trips table (or in a Driver Profile table), use Glide computed columns:
Daily totals
Extract β Date Only
Self Relation β match DriverID + DateOnly
Rollup β Count (Daily total trips)
Rollup β Sum (Daily total tonnage)
Monthly totals
Create a Formatted Month column (e.g. YYYY-MM)
Self Relation β match DriverID + Month
Rollup β Count (Monthly total trips)
Rollup β Sum (Monthly total tonnage)
This is fully dynamic β no scripts required.
β
4. Scaling Strategy
This structure works very well up to tens of thousands of rows.
If you expect more than ~250K rows in the Trips table (multi-year historical data, large fleet, etc.), then Glideβs computed columns will become less efficient. In that case you should switch to a summarized storage model for calculations:
For large datasets (> 250K rows)
Move raw data into one column as a JSON array
Use a JavaScript column to parse/filter/summarize the JSON
This avoids thousands of live relations/rollups
Much faster for dashboard summaries
Example strategy:
Store all trips for a user as a single JSON array in a Users table
Let one JavaScript column return daily/monthly totals by filtering the JSON
UI stays fast even with hundreds of thousands of historical records
That way Glide only loads one row per user, instead of 250k+.
β
5. Optional Summary Table (later)
If you want fast dashboards and charts, you can also create a Driver Summary table that holds: