Re: [SQL] Multitable uniqueness ?
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. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Multitable uniqueness ?
Bruno Wolff III wrote: On Wed, May 26, 2004 at 05:13:14 +0200, Andreas <[EMAIL PROTECTED]> wrote: Is there a way to have something like this : UNIQUE (table_1.id, table_2.xxx) Postgres doesn't support database constraints at this time which is what you would need to do this simply. Well, a simple way was to have a table_1-foreign key in the table 2. I just thought since there is: table_1 <--1:n-- table_x <--1:n-- table_2 and I hoped not having to add table_1 <--1:n-- table_2 just to have uniquness of an attribute of table_2 and the key of table_1 You can enforce this constraint by creating a third table That is more efford than to stuff the column into table_2. Thanks anyway ;) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] Multitable uniqueness ?
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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[SQL] PostgreSQL is hanging up !?
I have created several domains at Postgresql and I am trying to create some views on a domain "dcenter" using create or replace view cw_nodir_v as select ... However, my PostgreSQL hangs up.. on this domain only but not in other domains... Don't want to reboot PQ, and methods I can find out the root causes and fix the issues... and log I can look into.. Any help is appreciated. Thanks in advance. [EMAIL PROTECTED] itm]# ps -ef | grep post postgres 2162 1 0 May19 ?00:00:12 /usr/bin/postmaster -i -p 5432 postgres 2164 2162 0 May19 ?00:00:02 postgres: stats buffer process postgres 2165 2164 0 May19 ?00:00:05 postgres: stats collector process postgres 3016 2162 0 May19 ?00:00:00 postgres: eoc_sim eocdb 206.116.78.175 idle postgres 3018 2162 0 May19 ?00:00:03 postgres: eoc_sim eocdb 206.116.78.175 SELECT waiting postgres 14988 2162 0 15:42 ?00:00:00 postgres: eoc_core eocdb 206.116.78.128 SELECT waiting postgres 16129 2162 23 16:03 ?00:05:26 postgres: dcenter eocdb 206.116.78.50 SELECT postgres 16826 2162 0 16:17 ?00:00:00 postgres: dcenter eocdb 206.116.78.128 DROP VIEW waiting root 17269 3236 0 16:26 pts/300:00:00 grep post Louie Kwan [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
