abuse of inheritance?
Should I be using table inheritance in this scenario?
Table "contact" has name, address, phone, email, etc. columns.
Table "staff" inherits from "contact because it has many columns in
common with "contact".
But I want to query staff and get a list of staff-- and omit non-staff
contacts. The ONLY directive only works down the inheritance tree, so I
would have to do (something like) this to get a list of staff only:
SELECT staff.whatever
FROM staff, pg_class
WHERE staff.tableoid = pg_class.oid AND pg_class.relname = 'staff'
This strikes me as kinda funny and maybe I should not have inherited
staff from contact to begin with? Not really up to speed on the whole
object-relational concept yet. :-)
Alex Rice, Software Developer
Architectural Research Consultants, Inc.
alex_rice@arc.to
alrice@swcp.com
On Wed, 2002-07-10 at 15:46, Alex Rice wrote:
Should I be using table inheritance in this scenario?
Table "contact" has name, address, phone, email, etc. columns.
Table "staff" inherits from "contact because it has many columns in
common with "contact".But I want to query staff and get a list of staff-- and omit non-staff
contacts. The ONLY directive only works down the inheritance tree, so I
would have to do (something like) this to get a list of staff only:SELECT staff.whatever
FROM staff, pg_class
WHERE staff.tableoid = pg_class.oid AND pg_class.relname = 'staff'This strikes me as kinda funny and maybe I should not have inherited
staff from contact to begin with? Not really up to speed on the whole
object-relational concept yet. :-)
I don't understand what you're wanting here - is there a misprint
above? What you have done seems to be fine.
Assuming this structure:
contacts
|
staff
If you want a list of staff:
SELECT * FROM staff
If you want a list of non-staff:
SELECT * FROM ONLY contacts
If you want everyone:
SELECT * FROM contacts
If the structure is
contacts
|
+-------------------+-----------------+
| | |
staff salesmen bureaucrats
getting a list of non-staff needs a union:
SELECT col1, col2 FROM salesmen
UNION
SELECT col1, col2 FROM bureaucrats
or possibly an EXCEPT, if there are a lot of inherited tables:
SELECT col1, col2 FROM contacts
EXCEPT
SELECT col1, col2 FROM staff
On Wednesday, July 10, 2002, at 10:27 AM, Oliver Elphick wrote:
I don't understand what you're wanting here - is there a misprint
above? What you have done seems to be fine.
No misprint -- Thanks for the examples. Turns out I was just massively
confused about how SELECT works on inherited tables. Everything is
working just great now.
Alex Rice, Software Developer
Architectural Research Consultants, Inc.
alex_rice@arc.to
alrice@swcp.com
On Wed, 10 Jul 2002, Alex Rice wrote:
Should I be using table inheritance in this scenario?
Table "contact" has name, address, phone, email, etc. columns.
Table "staff" inherits from "contact because it has many columns in
common with "contact".
So I'm ok with relational theory, I think, and I know OO pretty
well, at least from a programmer's viewpoint.
But I'm unsure about this table inheritance thing. What is the advantage
of using inheritance over having a staff table with the staff columns
and a FK into the contact table? What are the disadvantages? Can anyone
point to some literature on this?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Curt Sampson writes:
So I'm ok with relational theory, I think, and I know OO pretty
well, at least from a programmer's viewpoint.But I'm unsure about this table inheritance thing. What is the advantage
of using inheritance over having a staff table with the staff columns
and a FK into the contact table? What are the disadvantages? Can anyone
point to some literature on this?
"The Third Manifesto" by CJ Date and Hugh Darwen is a great text for
exploring Object Relational ideas.
(These are the two who wrote the very popular "Guide to the SQL Standard")
On Thu, 11 Jul 2002, Arguile wrote:
Curt Sampson writes:
So I'm ok with relational theory, I think, and I know OO pretty
well, at least from a programmer's viewpoint.But I'm unsure about this table inheritance thing. What is the advantage
of using inheritance over having a staff table with the staff columns
and a FK into the contact table? What are the disadvantages? Can anyone
point to some literature on this?"The Third Manifesto" by CJ Date and Hugh Darwen is a great text for
exploring Object Relational ideas.
Yes, I've got that book, as well as the _Guide to the SQL Standard_
and many of Date's other books.
However, the appendex in T3M that deals with table inheritance can be
summarized as, "It's a stupid idea which can be implemented just as well
with a view, anyway." I tend to agree with this, but I was looking for
a contrary opinion to evaluate.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC