Re: Object-oriented thinking in SQL context?

From: Keith H Duggar <>
Date: Sat, 20 Jun 2009 21:00:06 -0700 (PDT)
Message-ID: <>

On Jun 17, 11:55 am, Marshall <> wrote:
> On Jun 17, 4:45 am, "Nilone" <> wrote:
> > "Bob Badour" <> wrote in message
> > >> Think 'class' ~ 'relation' (table)
> > > But that would not only be a blunder but a great blunder.
> > I'd like to clarify this for anyone coming from the OO side. If you map
> > class to relation, you're breaking the OO rule of encapsulation and reducing
> > the class to a simple aggregate type (struct). Presumably, you chose an
> > encapsulated, polymorphic abstraction device for a reason, or did you do so
> > just because you (or somebody at your company) read Lhotka's book? Classes
> > map to domains (types) in the relation model, but be aware that subclassing
> > is NOT subtyping.
> Speaking just for myself, when I am programming in an OO language,
> I map classes to whatever I feel like. OO really only provides the
> one unit of abstraction, the class. If the only tool you have is a
> class, everything looks like an object. Or something.
> In other words, when I want an abstraction for something in
> Java, I make it a class, because that's about the only choice.

Maybe this is a vocabulary mismatch problem; but it seems you're leaving out an important unit of abstraction: functions. Or what and I misunderstanding? (Note here I have in mind C++, Lisp, and other OO languages that support free functions.)

KHD Received on Sun Jun 21 2009 - 06:00:06 CEST

Original text of this message