Re: Mixing OO and DB
Date: Sun, 02 Mar 2008 09:45:35 -0500
Message-ID: <m2k5klp4kw.fsf_at_spe.com>
frebe <frebe73_at_gmail.com> writes:
>> >> You've asked this before and it has been fully answered.
>> >> The two components change at different rates for different
>> >> reasons, especially in distributed applications and when the
>> >> database supports multiple applications.
>>
>> > The only answer so far is about "denormailzation for perforance",
>> > which is a very debatable argument.
>>
>> It's not debatable at all.
>
> Ok, show me an example of such schema change that wouldn't affect
> the application code.
Denormalization for performance is just such a schema change. The data supported by the schema doesn't change, only the format. If you have SQL littering your application code, all of that has to be changed and retested. If you have an O-R mapping layer, for example, only the mapping code needs to change.
>> In addition, when a database supports multiple applications, the
>> schema may need to change for one application but the others should
>> be insulated from that change. This is common in many enterprises.
>
> Addning columns or tables wouldn't affect the other (old)
> applications. If you have other changes in mind, please show an
> example.
Changes to the schema to support new regulatory requirements are not uncommon. Sometimes these are simple additions, but they can also involve splitting or, less commonly, merging existing columns. Changing ordinality is another not infrequent change; an existing application can continue to function by using the primary or highest priority element on the many side of the relationship but a new application or component can take advantage of the full set.
During development, many shops are using iterative methods that require changes to both the schema and the application. When there is more than one project ongoing at the same time, insulating the application from the schema allows the new changes to be incorporated when it makes sense for the application team, rather than requiring all teams to change in lock step (a sure recipe for schedule slip).
In even medium sized organizations, all of these things are happening simultaneously, along with maintenance (which can be considered a variant of development). This is an issue that arises in practice frequently.
>> > Yes it is indeed bad design to force every SQL statement to be
>> > wrapped inside a method.
>>
>> So you prefer littering your code with embedded SQL?
>
> I wouldn't write exactly the same SQL statement in many different
> places, in that case I would use a function. But I would wrap every
> SQL statement in a function.
Did you mean to say that you _wouldn't_ wrap every SQL statement in a function? If so, you wouldn't pass a code review in my teams. The maintenance cost of not doing so is too high.
>> This isn't even an issue for the systems I work on.
>
> Why not?
I've recently been working on low latency systems in the
financial services industry. We have to keep the database, and any
other disk based storage, completely out of the critical path of the
business transaction or we won't meet our performance requirements.
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 02 2008 - 15:45:35 CET