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

Posted by SK. on Stack Overflow See other posts from Stack Overflow or by SK.
Published on 2010-04-15T11:02:56Z Indexed on 2010/04/15 11:13 UTC
Read the original article Hit count: 364

Filed under:
|

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.

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

v2
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.

© Stack Overflow or respective owner

Related posts about database-design

Related posts about oracle9i