On 31 Jul 2002, Hannu Krosing wrote: > I would not rush to drop advanced features, as they may be hard to put > back later.
If they are hard to put back, it's generally because the other code in the system that relates to it has changed, so you can't just bring back what is in the old versions in the CVS repository. But if the code was left in, that meant that someone had to make all of those integration changes you'd have to make to bring the code back; it's just they had to make it as they were adding new features and whatnot. If in the end you decide that the feature you didn't drop isn't important, you just did a lot of work for nothing. You may also slow down or stop the implementation of other, more useful features, because people find that the work to add them isn't worthwhile, due to having to change too much code. > If they stay in, even in broken form, then there wont be > nearly as much patches which make fixing them harder. Summary: someone always has to do the patches. It's just a question of whether you *might* do them *if* you decide to bring the feature back, or whether you *will* do them because the feature is there. > > What we (or I, anyway) are arguing is that > > the relational model does everything that table inheritance does, and at > > least as easily. > > The problem is that 'the relational model' does nothing by itself. It is > always the developers/DBAs who have to do things. Ok. So "the developer can do what table inheritance does just as easily in the relational model." > And at least for some brain shapes it is much more convenient to inherit > tables than to (re)factor stuff into several tables to simulate > inheritance using the relational model. I highly doubt that. Relating two tables to each other via a key, and joining them together, allows you to do everything that inheritance allows you to do, but also more. If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database.... > > Extending the model adds complexity without adding the > > ability to do things you couldn't easily do before. (This, IMHO, makes > > table inheritance quite inelegant.) > > Then explain why SQL99 has included inheritance ? Becuase SQL has a long, long history of doing things badly. The language has been non-relational in many ways from the very beginning. But Codd and Date argue that much better than I do, so I'd prefer you read their books and respond to those arguments. I can provide references if you need them. 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
