I have a design question re postgres's feature of inheritance, and I
need to determine if I should use this feature in this instance.
I have a heirachy of tables and some associated functions that are used
to cost (and store the costing) of manufacturing jobs.
The resulting 'job' may then become a job that is tracked through a work
flow, or included in a 'price list' or 'catalog'. Either way any given
'job' becomes a child of another header table - simply by adding 2
fields, 1 with the 'typeofjob' which determines which table will be used
to find and control the job, the other the key of that header table.
However it seems that this is what 'inheritance' as it exists in
postgres is for - correct? It seems I can achieve the same thing with
out using the 2 extra fields?
I've avoided using inheritance before, but am wondering what
considerations do I need to take on board to make this decision. Will it
make this easier or more difficult?
Thanks for any tips
pgsql-general by date
|Next:||From: Maurizio Faini||Date: 2003-09-25 07:14:32|
|Subject: Re: GET LAST ID INSERT|
|Previous:||From: Tom Lane||Date: 2003-09-25 04:29:59|
|Subject: Re: About GPL and proprietary software |