Alberto,
I feel your pain.
Simple parts family tables are not too bad, like for a series of fasteners. It's when users start creating things I'd call similar tables, not family tables. Cases where members of the family share no characteristic, but have had components and features glommed on or deleted.
For similar tables, the first step I use to manage it is to name all the parts and features with something significant. I can see it's a nut or a bolt - what's it in the assembly for?
Second, I group all the items that are there for a purpose - so a lid, its gasket, the screws, and washers are grouped into a lid_install group.
Then I look through the family table and match against the named items to see what columns could be eliminated from the table and replaced as part of a group column.
One thing I have found to be unhelpful is that instead of failing a defective instance on opening or retrieving it, WF5 just marches along. It takes some time to figure out why an item that is included in an instance row isn't displayed or retrieved when the reason is a dependency on an item that is not in the instance row. Instead of complaining it can't be placed, even during verify, related items just quietly dissappear. I've seen cases where a pattern of fasteners quietly collapses due to a lost reference and users fill in all the empty places. I can imagine the same thing happening with lost components in instances.
My best rework so far is 139 unnamed columns for a dozen instances. Since it was a similars table, not a family table, it only came down to 80 columns or so. No doubt others have come up with worse.
Another method that works well is to include a conditional via Program. The family table can have a value to control the Program. Groups work more easily than they did in previous versions, but Program can still be of great help. This is mentioned in http://portal.ptcuser.org/p/fo/st/topic=3&post=88178#p88178, courtesy of Guilherme Rocha.
What would help is if there was a place in the model to include a write-up of how the model works, in plain text. Something to give users a heads-up and act as a reminder. Same goes for any number of complex uses.
**************Search of PTCUser for "family table" ********************
Some interesting ones about the tables, not about repeat regions.
Michelle McMasters
Summary: To Family Table, or Not To Family Table
February 11, 2005 03:43 PM
http://portal.ptcuser.org/p/fo/st/topic=19&post=12753#p12753
Use Family Tabled UDFs to Speed Design and Reduce Drafting Effort
Last Updated By: David Haigh on Jun 05, 2009
http://portal.ptcuser.org/p/do/sd/topic=405&sid=533
