Hi @jmlowden and @koncvaker -
I checked in with some of our solution engineers on this!
In terms of evaluating Option A and Option B for Best Practice - Neither are “bad practice”.
Solution Requirements:
- Option A: Requires maintaining a barcode schema, managing printing (or ordering) the labels, and creating/maintaining Tulip trigger expression logic everywhere (which might be easier with reusable logic coming in the future)
- Option B: Requires understanding Tables queries/aggregations (and things like how to use Mode aggregation), and creating/maintaining special Tulip trigger expression logic everywhere.
There should be no performance concerns with either approach. And, for the record, 200k records is pretty minimal compared to other customer usage (we have customers with over 1 million records running aggregations and such just fine 
)
So really up to you which option you prefer here! As always, goal is to try and keep things simple, especially for future app builders in your org, so if you feel one of these options is simpler in that sense, that could be a good one to choose also.