Thread: Inheritance (general hints wanted)

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

Hi, I am not an expert but in object conception, a design pattern exists for the case you describe.  I don't
rememberwhich 
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)

O Achilleus Mantzios έγραψε στις Sep 20, 2005 :

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

Each table may be managed by its own applications,
whereas the accounting software will only need to read
and *update* the generic top level 'employee' table.

That would be great but unfortunately it isnt how
it works in PostgreSQL currently...

If PRIMARY KEYS were to be shared, a great
future (real) feature would be a
"isinstanceof" -like function on the PRIMARY KEY,
which tells if a row of the specific PK is from a certain table
in the hierarchy.

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

Judging from the replies i got, it seems that
inheritance is even less used than i initially thought.

I think that the OO term is a little too much advertised
in pgsql advocacy various acts, than actually engineered.

However, OO in pgsql besides being a traditionally cool
acronym, it also *could* prove to be extremely useful
when dealing with real problems.

Just a question, to all those who have implemented
inheritance in pgsql:

Are there any plans for dealing with the current problems?
Is it foundamentally hard to fix these problems?


-- 
-Achilleus

to All!

-- 
-Achilleus

Merry Christmas to you.

On Friday 23 December 2005 09:16 am, Achilleus Mantzios saith:
> to All!
>
> --
> -Achilleus
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq