database - When to use multiple foreign keys in a single table vs using associative tables? -

i'm trying understand when include multiple foreign keys table vs when use associative tables.

edit: added a diagram make easier understand.

i have settings system many settings specific division or classification. so, example, setting "number per team" might different in division 1, class in division 3, class a. , "minimum score" might different in division 1, class in division 1, class c. there settings have nothing division or classification feel should in same table.

so 1 way put div/class ids fks in settings table. settings don't depend on 1 or other (or either) null ids.

divisions ---------- id (int) label (varchar) description (varchar)  classification -------------- id (int) label (varchar) description (varchar)  settings --------- id (int) division_id (int) (fk) class_id (int) (fk) key (varchar) value (varchar) 

since there'd ever 1 combination of division, classification, , settings key, should work, right? "feels" wrong somehow - putting different events 1 competing in in competitor table. cannot guarantee won't come additional category/type they'd wish apply settings later. makes me want like:

divisions ---------- id (int) label (varchar) description (varchar)  classifications -------------- id (int) label (varchar) description (varchar)  settings --------- id (int) key (varchar) value (varchar)  settings_to_divisions ------------------------- setting_id (int) division_id (int)  settings_to_classifications ------------------------------ setting_id (int) class_id (int) 

i think allow easier growth when come new category (just create 'categories' , 'settings_to_categories' tables). i'd have whole set of duplicate records in settings table ([id], "min_score",5) , multiple, identical tables (id, label, description) associated items - create 1 unique setting record.

then happens when want different settings men vs women? add field settings table , hard code 'male' , 'female' strings record, null everywhere except settings gender specific? or @ other end of things, create separate 'gender' table 2 records , use in user table well? suddenly, i'm at:

divisions --------- id (int) label (varchar) description (varchar)  classifications --------------- id (int) label (varchar) description (varchar)  categories ---------- id (int) label (varchar) description (varchar)  type ---- id (int) label (varchar) description (varchar)  gender ------ id (int) label (varchar) description (varchar)  settings --------- id (int) key (varchar) value (varchar)  settings_to_divisions --------------------- setting_id (int) division_id (int)  settings_to_classifications --------------------------- setting_id (int) class_id (int)  settings_to_categories ---------------------- setting_id (int) category_id (int)  settings_to_type ---------------- setting_id (int) type_id (int)  settings_to_gender ------------------ setting_id (int) gender_id (int) 

it begins feel ... overly normalized. though maybe that's me.

i'm trying design intelligently though settings apply division 3 players, when tell me need further categories , application should behave differently division 3, class a, category green, rogue, male players vs female players, don't have redesign database or application in order get/set whatever different setting should be.

i'm sure isn't new concept. has recognized design pattern out there somewhere, it's hard trying search methods , approaches dealing situation might have 3 (or 5 or 8) different ways of associating single database entity.

i'm leaning toward association table approach (significant normalization), i'm not dba. making stupid design decision? negatives/challenges of approach? still different approach better?