Re: OOP real life example (was Re: Why is MySQL more - Mailing list pgsql-hackers
From | Curt Sampson |
---|---|
Subject | Re: OOP real life example (was Re: Why is MySQL more |
Date | |
Msg-id | Pine.NEB.4.44.0208131349420.14941-100000@angelic.cynic.net Whole thread Raw |
In response to | Re: OOP real life example (was Re: Why is MySQL more (Greg Copeland <greg@CopelandConsulting.Net>) |
Responses |
Re: OOP real life example (was Re: Why is MySQL more
Re: OOP real life example (was Re: Why is MySQL more |
List | pgsql-hackers |
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 copyis 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 <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
pgsql-hackers by date: