Database design problem: intermediate table between 2 tables may end up with too many results.

Question

I have to design a database to handle forms.

Basically, a form needs to go through (exactly) 7 people, one by one. Each person can either agree or decline a form.
If one declines, the chain stops and the following people don't even get notified that there is a form.

Right now I have thought of those 3 tables: FORM, PERSON, and RESPONSE inbetween. However, my first solution sounds too heavy because each form could have up to 7 responses.

Here we are with the table inbetween. That means that each successful form has 7 rows in the table RESPONSE.

Here we have the responding information directly inside the form. It looks ugly but at least keeps everything as singular as possible. On the bad side I can't track the response dates, but I don't think it is crucial for that matter.

What is your opinion on this? I feel like both of them are wrong and I don't know how to fix that.
If that matters, I'll be using Oracle 9.

Answer 1

Of the two, I'd advocate the first option, as it would be more flexible should the business process change, and require (say) 9 responses

If you're worried about storage, I would expect on average it to take less space to store "up to" 7 copies of the smaller form, than a single copy of the larger form.

Answer 2

First solution seems better. THen you can check if it is dissaproved by someone by doing simple SQL: ...WHERE response.isapproved=False. Otherwise you have to check all 7 fields in main table.