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)
