I can't see your problem.
UNIQUE (cp_id, stall_no) will inforce what you want.
Unless, you want to use the same customers table to show who visited
which stall. In that case you need another relation.
You can't have have a stall rented by and stall visited by at the same
table.
Andreas wrote:
> Jean-Luc Lachance schrieb:
>
>> Do you really need MANY-TO-MANY between customers and projects?
>> I can see customers owning many projects, but do you really have
>> projects belonging to many customers?
>
>
> In this case yes.
> projects (
> 1, 'x-fair 2003';
> 2, 'y-fair 2003';
> 3, 'x-fair 2004')
>
> customer (
> 1, 'X ltd';
> 2, 'Y';
> 3, 'Z')
>
> maybe all 3 have a stall on project 1.
> c1 and c2 attend project 2 where c2 has 2 stalls one inside and one
> outside the hall.
>
> I have the cust_project relation to tie other objects like proposals and
> letters to something small and common for all the communication to a
> customer.
>
>> If not, fold cust_proj into projects.
>> Otherwise, UNIQUE (cp_id, stall_no) on stalls should be enough.
>
>
>
> cp_id implies uniquness of (customer, project) couples.
> So with UNIQUE (cp_id, stall_no) we get
> --> UNIQUE (c_id, p_id, stall_no)
> This'd be too much. Stall_no is the number of the cubicles the customers
> rent.
> It needs to be unique within on project so that we can relate on a
> specific spot on the area to send visitors when they ask us and we print
> those numbers in the flyer.
>
>
>