At a minimum, a join table would have the primary keys of the two tables it's connecting as foreign keys. For example, if you're joining Estimates and Products, you might have EstimateID and ProductID.
Beyond that, you would have additional fields as needed for the particular business flow. For example, you might choose to have a primary key for the join table record itself (e.g., EstimateProductJoinID). Some developers do this to make it easier to script locating a specific record in the join table during scripting; others simply use the combination of the two keys from the parent tables. Mostly a personal choice.
Other possibilities include anything that is unique to the join table record. Perhaps the join table record connecting an estimate and a product is a line item (because the connection between the estimate and the product represents one line of the estimate)? If so, it might have a unit price. That would go into the join table. Additional possibiities might be quantity, line total (which might be a calculation), discount, description, and so forth.
Basically, think in terms of what each record in the join table represents (i.e., what entity is it?). That will guide you towards what fields belong there. It's a data modeling question more than a mechanical one. (Go through the exercises in the Data Modeling chapter of the Advanced FTS to get a handle on the concepts.)
Thank you Mike
I progressed to the DATA/Relationships in the Advanced Training.
I'll do my best now
This is is tough, complete new level of thinking to me.
Good! New makes the brain grow!