Re: An object-oriented network DBMS from relational DBMS point of view

Sampo Syreeni wrote:
> On Mar 11, 6:57 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > There is a general tendency I have observed when people come
> > across a new way of doing things that they try to map their old
> > way of doing things on to the new way. That enables them to
> > use techniques they already have under the new system.
>
> Another, more productive reason would be to see what precisely each of
> the two systems has to contribute, and to use the mapping/analogy/
> morphism to arrive at new perspectives on both. For me the prime
> insight from this sort of thing into OO has been that relational
> normal forms have a lot to say about refactoring, and vice versa, I
> had a hard time understanding polymorphism under the RM till I went
> through an OO mapping.

I've generally come to conclude that polymorphism is an antithesis of set theory. If we are talking about specific instances (such as "employee"), then generally it would correspond to a given record (row) in a table. However, if it is a category, then polymorphism limits you to mutually-exclusive choices and is a lot of code rework to un-mutual-ify. This tends to be an inflexible modeling technique as the most flexible business modeling treat features like a mix-and- match buffet. (Validation prevents combos that are not allowed.) Customers want onion rings *and* fries, not one or the other. Poly is anti-mix-and-match, at least not without creating Rube Goldberg-like code contraptions, remeniscent of messes like Visitor pattern.

-T- Received on Tue Mar 13 2007 - 16:11:14 CET