Re: Mixing OO and DB

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:ce09666e-ca81-4da4-95e2-11c358049614_at_h11g2000prf.googlegroups.com...
> On Mar 9, 6:08 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >
> > I don't agree with this. You're equating the database schema with the
> > database implementation. The schema specifies what information is to be
and
> > can be recorded. As such the schema is an integral part of the
application
> > specification, and it cannot be decoupled, but that doesn't mean that
the
> > database implementation cannot. The schema does not specify how
information
> > is physically recorded, nor does it specify the process by which the
> > recording takes place. That belongs to the implementation, and that can
> > certainly be decoupled and probably should be.
>
> Just so.
>
> This is a difficult distinction for a lot of people to make, however.
> Vanishing few software tools even attempt to make any distinction
> between the logical and physical, so few people have an opportunity
> to see the distinction in action.
>
>
In addition, the logical/physical distinction has not been defined consistently among all the people teaching other people about databases. I learned relational DB practice back in the mid 1980s, and learned SQL a couple of years later. The logical/physical distinction was decribed for me by my mentors in ways that are subtly different from the way the same distinction is discussed in c.d.t.

Actually, when I first learned this stuff, the distinction made was conceptual/logical/physical.

As far as modeling tools go, the tool we used in the mid 1980s was pencil and paper or whiteboard and marker. As far as real software tools go, the only one I used much was "Data Architect" about 2000. Data Architect, at that time, managed two kinds of data models: conceptual and physical.

The physical model contained schema objects and database objects. The database objects, things like Oracle tablespaces, were completly invisible to the application programmer. The schema objects, things like tables and procedures were generally visible to the application programmer across the interface.

While this does NOT address the point you make above thoroughly, it's a far cry from not even attempting to make any distinction. I don't know what's become of DA in recent years.

I can add more detail about the conceptual/logical/physical distinction as I learned it. However, every time I post such material in c.d.t. It gets dismissed as simply "wrong", and I get told to read enough D&D to become orthodox. I don't need to repeat this exercise.

Marshall, if you are truly interested, perhaps we can exchange e-mails. I don't intend to convert you to the way of thinking that I learned back in the 1980s. But I think there's enough ore mixed in with the slag there so that you should extract the ore and integrate it into your emerging world view. Received on Mon Mar 10 2008 - 13:43:14 CET