>RepairChecklist - has a row for every kind of repair that can be done.

Just a comment to add - in general this list can hardly be finite. There's an infinite number of ways things may go wrong, and we may expect that this list may get extended anytime. If this is what was supposed to be fit into 250 yes/no columns (represented by separate logicals or grouped into a long string, never mind), they'd either have to group real events into those 250, or 250 may soon be not enough. This is what practice has taught me far before theory did, and I'm glad theory endorses this. So, instead of having 250 Tees and Effs, where just two or three would be T's, we'll have 2 or 3 records for things picked from this list.

Seeing that Michelle has a pretty much definite list of things to repair, I gather the decision on this subject was already made by her user, and not the one I'd have recommended. It leads to somewhat more rigid design, but then, it's her app, her user, and she said it's a back corner of the app. So what, any excuse is good if we want to discuss some design theory :)