On 12 Aug 2002, Hannu Krosing wrote: > Are you saying that inheritance in SQL is something fundamentally > different than inheritance in OO languages ?
Yes. > > (For example, the distinction > > between types and instances of types is critical in OO theory. What are > > the TI equivalants of this?) > > If by TI you mean type instance.... Sorry, I shouldn't have abbreviated this. By "TI" I meant "table inheritance." > then the equivalent of of an instance is > a relation (i.e. one row in an (inherited) table). As I understand it, one row in a table, inherited or not, is a tuple, not a relation. The definitions I'm familar with are Date's: a relation is a header, describing the types of attributes within the tuple, and a set of tuples conforming to that header, and a relvar is a variable that holds such a relation. (His definitions seem to be the ones in common use--Korth/Silberschatz agree with him, though they don't use the relvar concept AFIK.) So is an instance a relation (a set of tuples) or a tuple? If the former, consider the following argument. In an object oriented program I can have a class C, and a subclass C' that inherits from C. Now, in any situation that calls for an instance of C, I can instead use an instance of C'. This is polymorphism. Now, if an instance is equivalant to tuple, and a relation inherits from another relation, I'd guess that a relation is equivalant to a class. But given relation R' inheriting from relation R, does that mean that I can use a tuple from R' anywhere I could use a tuple from R? No, obviously not, as the two tuples have a different number of attributes, to start with. So this analogy is now breaking down. I suppose I could try to work out here if you really mean that (using the strict Date sense of the terms here) the relvars are classes, and the relations that they hold are instances. But that seems to get a bit sticky too. I think it's better if I wait at this point for you to provide some further clarification. Would you mind doing so? Specifically, what is the equivalant of a class, and what is the equivalant of an instance? What are the consequences of this, if you know them? > All _simple_ inheritance problems are easily solved by simple relational > solutions. The general problem of much more typing and debugging, less > clues for optimiser etc. are not solved by _simple_ relational > solutions. Can you please give me two or three examples of problems that are not solved by simple relational solutions, and how table inheritance solves them? > Of maybe people are diversifying, using inheritance for is-a > relationships and relational model for has-a relationships. Well, it seems to me that the relational model better supports the is-a relationship. With the relational model, I can specify a column in a table that specifies what that particular entity is, and that can be set to one and only one value. With the table inheritance model, how are we ensuring that, if tables R' and R'' both inherit from R, when a tuple is in R' relating to another tuple in R (or is that the same tuple), there's not also such a relation between a tuple in R'' and R? 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
