By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,835 Members | 2,305 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,835 IT Pros & Developers. It's quick & easy.

To inherit or not to inherit

P: n/a
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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.