a Q about BO groups, and adding fields

Jaymer

Subordinate to my Customer file, I have Workorders.
For Workorders, there all types of "work" tickets... I made a group "TicketGroup"

TicketGroup: contains BOs for
Pickups
Deliveries
Estimate
Intake
Repair
Labor ... and a few more

All these tickets have common elements:
date, time, person, descr, status, open/closed, timestamps, etc. plus specific fields related to that ticket

So I have a nice screen that shows all the Tickets under a workorder... and you can see all the chronological events.

Now, as the system matures, the customer needs a field from Labor, for example, to show on the TicketGroup grid (this is a "peer-multiple" grid embedded in a form in a tab).
And those familiar with BO Groups know that in order to do that, the desired field must exist in ALL BOs in that group.

Here's the issue...
from my training, we don't always want to "bloat" records by adding fields we don't need - or make them much longer than really needed.
So, since this is needed for a business reason, and I don't see a way around it, SHOULD IT BUG ME WHEN I HAVE TO ADD A DATABASE COLUMN TO ALL THESE TABLES WHEN i am only going to populate it in one of them? Its basically a varchar and will be null in all BOs except the one thats needed. It just goes against my grain, but I don't see a way around it.
Of course, you do it once, THEN you have to do it again... and again... and again.

Eventually, you keep adding columns to the grid and many are blank and just take up space... because the chronological history of a Workorder MAY NEVER HAVE a Labor ticket on it, for example, but when it does, we've got the column for that 1 field they needed to show for Labor.

I probably shouldn't worry about it, but just need to see how others (who actually use BO Groups) deal with this issue.
thx

tford

I don't loose any sleep about adding attributes that are blank in some (or many) instances. Storage is cheap these days compared to the day when you and I were first trained.

Moving past that speed bump in your mind allows you to keep leveraging Aware IM to do what it does best .. rapid [quality] application development.

I look at issues like this as a speed bump rather than a road block. That paradigm helps me to simply slow down and consider the alternatives, then go full steam ahead once I've decided to proceed over the speed bump.