On 12 Aug 2002, Greg Copeland wrote:
> You're constantly confusing Postgres' implementation with a "desired"
> implementation.
No. I'm still trying to figure out what the desired implementation
actually is. This is documented nowhere.
> If you're so keen on examples, please provide one that justifies such a
> boastful statement.
You appear to be saying I should provide an example that proves there
exists no table inheritance configuration that cannot easily be done
with a relational implementation. That's not possible to do, sorry.
I will revise my opinion the instant someone shows me something that I
can't do relationally, or is easy to implement with inheritance, and
difficult with relational methods. Now you know what you need to do, and
if you have no example, we can drop the whole thing. But I am honestly
interested to see just what it is that makes table inheritance so great.
> > Are we then assuming that tuples in the child tables do not appear
> > in the base table? That's more or less what I'd assumed when I
> > originally heard about table inheritance (after all, instantiating
> > a child object does not automatically instantiate a separate copy
> > of the parent object), but the SQL standard, postgres, and I believe other
> > systems make the exact opposite assumption.
>
> That's actually my exact assumption...that is, that tuples in the parent
> did not exist in the child.
Sorry, by "opposite assumption," I meant these two opposites:
1. Tuples in child tables appear in the parent table.
2. Tuples in child tables do not appear in the parent table.
Take your pick, keeping in mind that the sources I know of (Appendix E of _The
Third Manifesto_, _Database Systems Concepts_ (ISTR), the SQL standard and
postgres currently all assume #1.
If we find the one we pick is unworkable, we can always go back
and try the other.
> > If the child table tuples do appear in the parent, you've now got
> > a situation analogous to the current postgres situation where a
> > constraint on the parent table is an outright lie. (I'm thinking
> > of the UNIQUE constraint which guarantees that all values in a
> [snip]
>
> I knew that there are *implementation* issues with postgres that causes
> problems with constraints, etc...I didn't realize that was the reason.
Well, assuming we are mapping inheritance back into relational stuff
behind the scenes (which it appears to me we are doing now), we can just
map back to the relation method I demonstrated earlier of doing what
someone wanted to do with table inheritance (child tables contain only
foreign key and child-specific data; parent table contains primary key
and all parent data) and that will fix the implementation problem.
Or people have proposed other things, such as cross-table constraints,
to try to do this.
> Well, you seem to be making references to "...SQL standard, postgres,
> and I believe other systems...". I was counting on you or someone else
> to point us to existing references.
Well, counting on me is not good, since the whole reason I started this
was because I found the issue confusing in part due to the lack of any
obvious standards here that I could find. :-) But here's what I do have:
Date, Darwen, _Foundation for Future Database Systems, The
Third Manefesto (Second Edition)_. Appendex E.
Silberschatz, Korth, Sudarshan, _Database Systems Concepts
(Fourth Edition)_. I think it's around chapter 9. (My copy is
at home right now.)
SQL Standard. I don't have it handy. Anyone? Anyone? Bueller?
Postgres. Known broken implementation, but we can at least poke
stuff into it and see what it does.
In addition, OO programming gets mentioned ocassionally. I don't
think that table inheritance is anything related (and I've spent
a lot of time in the last couple of years developing methods to
make my OO programs and relational databases play nice with each
other), but it might help to have some idea of what people to do
connect the two, in case some people think that they are or should
be connected. You can start by checking out this page for a few
ways of creating objects from database information:
http://www.martinfowler.com/isa/inheritanceMappers.html
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
