Skip site navigation (1) Skip section navigation (2)

Re: Multitable uniqueness ?

From: Jean-Luc Lachance <jllachan(at)sympatico(dot)ca>
To: Andreas <maps(dot)on(at)gmx(dot)net>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Multitable uniqueness ?
Date: 2004-05-27 13:08:35
Message-ID: 40B5E853.5060008@sympatico.ca (view raw or flat)
Thread:
Lists: pgsql-sql
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.
> 
> 
> 


In response to

pgsql-sql by date

Next:From: Louie KwanDate: 2004-05-27 20:43:47
Subject: PostgreSQL is hanging up !?
Previous:From: Willem de JongDate: 2004-05-27 11:14:58
Subject: Re: sum ( time) problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group