Re: [SQL] I'm stumped

2004-12-21 Thread thomas.silvi
Doug Y a écrit :
I can't figure out an efficient way to do this. Basically I had a 
typical 3-tier relationship:
(Employee -> Department -> Division)
However, at some point the need to move employees arose, but instead 
of changing the key in the emp table, we now have an over-ride table, 
so a history can be tracked.

If I want to get the info for a particular employee, its a pretty 
simple deal, however, getting all the employees for a dept or division 
has become troublesome.

A very simplified schema:
divisions ( div_id, div_name );
departments ( dept_id, dept_name, div_id );
employees ( emp_id, emp_name, dept_id );
emp_dept ( emp_id, dept_id, active, changed_by, changed_when );
The original way that worked well:
SELECT v.div_name, d.dept_id, e.emp_id, e.emp_name
  FROM divisions v
   INNER JOIN departments d
   ON d.div_id = v.div_id
   INNER JOIN employees e
   ON e.dept_id = d.dept_id
 WHERE v.div_id = 123;
What was initially tried:
SELECT v.div_name, COALESCE(ed.dept_id, d.dept_id), e.emp_id, e.emp_name
  FROM divisions v
   INNER JOIN departments d
   ON d.div_id = v.div_id
   INNER JOIN employees e
   ON e.dept_id = d.dept_id
   LEFT JOIN emp_dept ed
  ON ed.emp_id = e.emp_id AND ed.active = true
 WHERE v.div_id = 123;
This query is flawed, as it still always puts the employees in their 
original div, but reports the new dept. Which we didn't catch as a 
problem until emps were moved to depts in a different division.

I tried creating a function:
CREATE OR REPLACE FUNCTION get_empdept(int4) RETURNS int4 AS '
SELECT CASE WHEN ed.dept_id IS NOT NULL
THEN ed.dept_id
ELSE e.dept_id END
  FROM employees AS e
   LEFT JOIN emp_dept AS ed
  ON ed.emp_id = e.emp_id AND ed.active = true
 WHERE e.emp_id = $1
' LANGUAGE SQL STABLE;
And then tried:
SELECT v.div_name, d.dept_id, e.emp_id, e.emp_name
  FROM divisions v
   INNER JOIN departments d
   ON d.div_id = v.div_id
   INNER JOIN employees e
   ON get_empdept(e.emp_id) = d.dept_id
 WHERE v.div_id = 123;
However since the function is not immutable (since it does a query), I 
can't create an index, and the join always does a seq scan.

I also thought to create a view, but I don't believe Postgres supports 
indexed views. It was always using a seq scan too.

The above examples are actually quite simplified, as several other 
tables get joined along the way, I'm not sure a UNION would work or 
not, how would it exclude the ones that match the dept_id in the emp 
table for those emps that match on the over-ride table?

Any suggestions?
Hello,
have you an index on emp_dept on emp_id, dept_id ?
what about this ?
SELECTv.div_name, d.dept_id, e.emp_id, e.emp_name
FROMdivisions v
   INNER JOIN departments d ON d.div_id = v.div_id
   INNER JOIN employees e ON e.dept_id = d.dept_id
WHERENOT EXISTS (SELECT 1 FROM emp_dept ed WHERE ed.emp_id = e.emp_id)
ANDv.div_id = 2
UNION ALL
SELECTv.div_name, d.dept_id, e.emp_id, e.emp_name
FROMdivisions v
   INNER JOIN departments d ON d.div_id = v.div_id
   INNER JOIN emp_dept ed ON d.dept_id = ed.dept_id
   INNER JOIN employees e ON e.emp_id = ed.emp_id
WHEREed.active=true
ANDv.div_id = 2
Regards,
Thomas
Thanks
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [SQL] column names, types, properties for a table

2005-09-08 Thread thomas.silvi


  Hello,
   there is the view "columns" in the schema "information_schema" that 
can give you most of the informations you need

   ( for PosgreSQL version >= 7.4.8 if I'm right).

   SELECT   *
   FROM information_schema.columns
   WHEREtable_name = 'mytable';

   See 
http://www.postgresql.org/docs/8.0/interactive/infoschema-columns.html#AEN26185
 or  
http://www.postgresql.org/docs/8.0/static/infoschema-columns.html#AEN26185


  Regards,
Thomas

Roger Tannous a écrit :

Hi, 


Is it possible to issue an SQL query that lists column names, types (int,
varchar, boolean, etc.), properties (like NOT NULL or UNIQUE) 
for a given table name ?



Regards,
Roger Tannous.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

 




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [SQL] Inheritance (general hints wanted)

2005-09-20 Thread thomas.silvi

   Hi,
  I am not an expert but in object conception, a design pattern
  exists for the case you describe.  I don't remember which
one. The idea is to add an attribute that references the job
of the employee. The inheritance is not on the side of the
employee but on the side of the job. So if the job of the
employee changes, it easy to do it.

an example in pseudo-code

class basic_job
 string  name

class sailor_job inherit basic_job

class employee
 string  name
 basic_job   job


  Hope it helps,

  Regards,
  Thomas
>
> Hi,
>
> I think i have reached a point in my PgSQL years
> that i am seriously thinking of using inheritance.
>
> The situation is simple: An new entity (tanker vessels crew)
> is about to be modeled, and i suspect
> there will be a future need to include
> the rest of 'workers' besides 'sailors',
> IOW i suspect a future need to generalize.
>
> So i am thinking of a two-level tree hierarchy,
> where there is a simple table emp (employee),
> and a direct child 'tankerscrew'. Later
> there may be 'masons', 'office_employees'
> and so on.
>
> The problem is that while i find this approach
> attractive, i have never used PostgreSQL
> inheritance exhaustively and in production scale.
>
> Furthermore, i also feel that not many
> people have used inheritance in a massive fashion
> (besides playing with a test db).
>
> Of course i can do it with separate uncoupled tables,
> that can be later related with some views.
>
> So that leads to the final question:
> -What are the main PROs of inheritance that cant be beat
> by other solutions, and
> -Are there any traps someone must have in mind when he
> prepares for such a design?
>
> Thanx in advance.
> --
> -Achilleus
>
>
> ---(end of
broadcast)---
> TIP 2: Don't 'kill -9' the postmaster
>

 A+
Tom

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq