jcombs_31

I think this is what I was looking for. Was having a mental block. Thanks ignace. I think though this leads to an additional table. Table 2 in my scenario also has additional data, for example notes, creation date, etc...

What I'm really doing is creating an enum of sorts. I just need that enum to be flexible which is why I'm using another table to populate it. The extraneous data is someone irrelevant. Ultimately this is a relation between 2 tables. <table1> id action <table2> id field1 field2 field3 .... The values for table2 will be driven from the options available in table1.

Ok, I for whatever reason just feel like I'm going about the design wrong, I guess because I never had to build a table like this. We use an internal system with a number of fields that we need to conduct reviews on. Each of these will be 'graded' with a follow up action. I guess this is the only real way to do it, just wanted to be sure. Thanks for the answer.

I'm thinking maybe I'm going about this wrong, so here it goes. I have a table, lets call it actions, defined with only a couple fields (id, summary). Data would be like: 1 Update 2 Follow Up 3 Close .... I have a table with a number or fields that would reference actions. Ultimately this is for a review of sorts. I need to have about 10-15 fields reference the available 'actions' as defined in the actions table. Would I have to define each foreign key separately, or is there a better way to accomplish what I want. Table 2 has a number for foreign keys. field 1 => action field 2 => action field 3 => action So the constraints look like foreign key (field1) references actions(id) foreign key (field2) references actions(id) foreign key (field3) references actions(id) I thought this could be written as: foreign key(field1, field2, field2) references actions(id), but apparently I was sadly mistaken. I've been away from any type of dev for a while, so any thoughts would be appreciated.

I've been happy with Netbeans.