Re: Mixing OO and DB

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 16 Mar 2008 20:44:20 GMT
Message-ID: <EEfDj.21532$0o7.19375_at_newssvr13.news.prodigy.net>

"Patrick May" <pjm_at_spe.com> wrote in message news:m2wso2vb5i.fsf_at_spe.com...

> "Brian Selzer" <brian_at_selzer-software.com> writes:

>> "Patrick May" <pjm_at_spe.com> wrote in message
>> news:m2wso9i9be.fsf_at_spe.com...

>>>>>     In any case, we're getting a little far afield from the
>>>>> original question.  In enterprise systems, denormalization for
>>>>> performance does take place.  This is just one of several reasons
>>>>> for decoupling the application logic from the database schema.
>>>>
>>>> I don't agree with this.  You're equating the database schema with
>>>> the database implementation.
>>>
>>>     Not at all.  I don't see where you get that from what I wrote.
>>>
>>>> The schema specifies what information is to be and can be recorded.
>>>
>>>     Yes.
>>>
>>>> As such the schema is an integral part of the application
>>>> specification, and it cannot be decoupled
>>>
>>>     No.  One schema can support multiple applications, and often
>>> does in enterprise environments.  One application can be supported
>>> by different schemas -- there is not one and only one way to
>>> represent the information required by the application.
>>

>> I'll buy that a schema can be part of multiple applications, but
>> that there can be multiple ways to represent the same information
>> does not alter what information is to be and can be recorded.

>
>     First, please excuse the delay in replying.  I was busy
> destroying the world by replacing relational databases with in-memory
> distributed object repositories.  ;-)
>
>     We seem to be in agreement that different specific schemas can
> provide access to the same underlying information.  That suggests that
> your statement that ". . . the schema is an integral part of the
> application specification, and it cannot be decoupled . . ." needs
> clarification.  Would you agree with the formulation "The logical
> schema is an integral part of the application specification."?  By
> "logical schema" I mean the implementation independent set of data
> that supports the application.
>
>     If you agree with this, the second half of your claim ". . . and
> it cannot be decoupled" is clearly incorrect because the application
> implementation deals with the physical schema.  Since you agree that
> multiple different physical schemas are possible, decoupling the
> application from any particular set of those is both possible and good
> design.
>

No, it isn't incorrect. Whenever a schema evolves, views are often used to provide backward compatibility for existing applications. An application need not concern itself with whether it is accessing a view or a table; therefore it is not necessarily tied to any physical schema.

>     Further, the view that the schema is integral to the application
> is very data centric.  Different applications may need the data in
> different forms, not all of which are relational.  There is therefore
> a need to translate between the data structures, which is another good
> reason to decouple the application from the specific physical schema
> being used.
>

If by data centric you mean that the information that is to be and can be recorded must be specified before even considering how that information may behave, then I agree: it is a data centric view. But again, you're laboring under the delusion that an application must be tied to a physical schema.

>>>     Even if an application uses the database system's capabilities
>>> to implement some application functionality, there are still
>>> changes to the underlying schema that do not, or should not,
>>> require change to the applications that use that schema.  This is
>>> why approaches like dependency inversion are useful.  The
>>> application depends on an interface and the combination of database
>>> schema and any logic running in the database implements that
>>> interface.  Either can change without impacting the other.
>>

>> The database contains that which can be manipulated. An application
>> is that which does the manipulating. These are completely different
>> species of functionality.

>
>     The database sometimes contains some of that which can be
> manipulated.
>

I don't follow you. Please elaborate.

>     I agree that they are different species of functionality.  That's
> another good reason (or a restatement of one of my reasons) for
> decoupling them.
>
> Sincerely,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
>                       | systems design and implementation.
>          pjm_at_spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA) 

Received on Sun Mar 16 2008 - 21:44:20 CET