Re: Mixing OO and DB
Date: Mon, 10 Mar 2008 10:57:52 -0300
Message-ID: <47d53e64$0$4037$9a566e8b_at_news.aliant.net>
David Cressey wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message
>
>>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.
I don't recall what you were taught about conceptual/logical/physical,
and I am not sure exactly what D&D's position is. However, the standard
vocabularies make the distinctions clear:
Conceptual is the domain of all information of interest to humans.
Logical is the domain of data, that subset of information suitably
represented for machine processing without reference to any specific device.
Physical is the domain of actual devices.
Something that might be logical from one perspective might be physical from another. For example, someone who writes device drivers for hard drives might consider the IOCTL or similar interfaces logical interfaces to the physical interaction with the I/O chips. Someone who writes dbms internals might look at various indexes, logs and heaps as logical interfaces to the IOCTL interface to the physical hard drive. A DBA would consider relations logical interfaces to data and those same indexes etc. as means to physically rearrange storage for performance.
The standard vocabularies also make clear the distinction between internal and external.
Most discussions on c.d.t would take a perspective similar to the DBA's. Received on Mon Mar 10 2008 - 14:57:52 CET