Re: Mixing OO and DB
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 03 Mar 2008 08:36:26 -0400
Message-ID: <47cbf0cc$0$4067$9a566e8b_at_news.aliant.net>
>>frebe <freb..._at_gmail.com> writes:
>>
>>>On 2 Mar, 15:45, Patrick May <p..._at_spe.com> wrote:
>>>
>>>>frebe <freb..._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.
>>
>>>Still no example. I was asking for the schema before and after such
>>>change. Then we could evaluate if the application code would have to
>>>change too, or not.
>>
>> I'm not sure why you need an example here. Have you never seen
>>denormaliztion done for performance reasons? Do you not realize the
>>the entire point of doing so is to reduce the bottleneck posed by the
>>database without changing the external behavior of the business logic
>>that uses the database?
>>
>> One common denormalization technique is to eliminate a join by
>>adding columns to one table that replicate data in another table that
>>has a one-to-many relationship with the table being denormalized. The
>>business logic shouldn't have to change just because the schema does.
Date: Mon, 03 Mar 2008 08:36:26 -0400
Message-ID: <47cbf0cc$0$4067$9a566e8b_at_news.aliant.net>
frebe wrote:
> On 2 Mar, 20:24, Patrick May <p..._at_spe.com> wrote: >
>>frebe <freb..._at_gmail.com> writes:
>>
>>>On 2 Mar, 15:45, Patrick May <p..._at_spe.com> wrote:
>>>
>>>>frebe <freb..._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.
>>
>>>Still no example. I was asking for the schema before and after such
>>>change. Then we could evaluate if the application code would have to
>>>change too, or not.
>>
>> I'm not sure why you need an example here. Have you never seen
>>denormaliztion done for performance reasons? Do you not realize the
>>the entire point of doing so is to reduce the bottleneck posed by the
>>database without changing the external behavior of the business logic
>>that uses the database?
>>
>> One common denormalization technique is to eliminate a join by
>>adding columns to one table that replicate data in another table that
>>has a one-to-many relationship with the table being denormalized. The
>>business logic shouldn't have to change just because the schema does.
What an idiot! The cost of doing updates and enforcing data integrity (otherwise known as business rules) will go through the roof. That's not exactly a performance benefit in the first place.
And if someone really needs those performance characteristics, it's better to physically cluster the data without changing logical interface.
As I said before, his idea demonstrates abject ignorance.
[snip] Received on Mon Mar 03 2008 - 13:36:26 CET