Multi Relationships

[John]

Is it a bad design to have a primary key a procedures table, be a child key
in multiple sub procedure tables. I am writing a database that has a
procedure table with 25 yes/no fields. If a field is checked yes then a
button will enable. Clicking the button will open a second form. My design
has the form open using the field value from the previous form. It seems to
work fine for now, but I have not started building queries yet and am trying
to avoid trouble.

You help is greatly appreciated.

John

 

[John Vinson]

Is it a bad design to have a primary key a procedures table, be a child key
in multiple sub procedure tables.

Not at all. This is called "Subclassing" and is the most common reason
one would create a one to one relationship. This would make sense if
the various subprocedures had different types of information that
needed to be stored.

I am writing a database that has a
procedure table with 25 yes/no fields. If a field is checked yes then a
button will enable. Clicking the button will open a second form. My design
has the form open using the field value from the previous form. It seems to
work fine for now, but I have not started building queries yet and am trying
to avoid trouble.

The 25 yes/no fields IS a problem though! I would *strongly* recommend
a different approach. What if you someday come up with a 26th
subprocedure? or need to delete a subprocedure? Change the structure
of your table, all your queries, and all your forms and reports? Ouch!