Re: Mixing OO and DB
Date: Sun, 16 Mar 2008 20:44:20 GMT
"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
>>>>> 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