Re: Mixing OO and DB

topmind wrote:

>
>
>Robert Martin wrote:
>> On 2008-03-05 00:20:57 -0600, frebe <frebe73_at_gmail.com> said:
>>
>> > The reason OO people like to "decouple" the SQL statements is:
>> > 1. OO languages doesn't have good support for embedding SQL.
>> > 2. OO like to model data as a network graph, in opposite to the
>> > relational model.

The relational model can represent network structures just fine (although some of the diehards in cdt really dislike the idea). Traditional query languages such as original SQL are a bit weak for manipulating such structures, but that isn't an argument against the relational model per se.

>> OO people like to decouple SQL because
>> 1. They don't like mixing high level policy code with low level detail
>> code. They'd rather partition their code based on abstraction level.
>

>[...] SQL is *not* any more "low level" than your
>app language (unless you are using it wrong).

I always find use of the terms "abstract" and "low-level" terribly suspect. It's more useful to think in terms of the common (usually, the "abstract") vs. the specific. We always strive to factor out the common from the specific; this is what we call "abstraction".

In the context of a single application with a variety of storage backends, which is what the OO world usually thinks of, and Robert Martin in this case, abstraction means providing a common application/storage interface that allows storage backends to be added and replaced without any change to the common application code.

In the context of a single data storage with a variety of different applications, which is what the RDBMS world usually assumes, abstraction means providing a common application/storage interface that allows applications to be added and replaced without any change to the common storage facility.

They're both abstraction, but in the opposite direction.

-- 
Reinier Post