On Tue, 2002-08-13 at 00:16, Curt Sampson wrote: > 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.
I think here-in is the first problem. You seem to insist that the world can only allow for one or the other and that the two approaches are mutually exclusive. I tends to think that there is room for both. One would also seem to allow that they can actually be complimentary (referring to Hannu's recent is-a & has-a inheritance comments). Can we let go of x is better than y and just concentrate on how y can be made better without regard for x? After it's all said and done, who knows, everyone might agree that table inheritance is just a plain, bad idea. > > > > 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. This is what I imagined the preferred solution would be, however, I'm also assuming it would be the more complex to implement *properly*. > > Or people have proposed other things, such as cross-table constraints, > to try to do this. Ya, I was kicking this idea around in my head tonight. Didn't get far on it. So I should look for postings in the archive about this specific implementation? > > > 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. Is this a book or a paper. I have a paper that I've been reading (ack...very, very dry) by these guys of the same name. > > 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? So the SQL standard does address table inheritance? Not that this means I feel that they've done the right thing...but what did the specification have to say on the subject? Any online references? > > 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 Yes. I think I'm starting to buy into that too, however, I'm not sure that it has to mean that no value is within. In other words, I'm still on the fence on a) table inheritance really makes much "OO" sense and b) even if it does or does not, is there value in any form of it's implementation (whatever the end result looks like) . > 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 > Thanks. Funny, I was reading that just the other day. ;) Greg
signature.asc
Description: This is a digitally signed message part
