Re: Mixing OO and DB
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 04 Mar 2008 18:45:16 -0400
Message-ID: <47cdd101$0$4036$9a566e8b_at_news.aliant.net>
>
> [...]
>
>
>
> Like I said before, they usually change for the SAME reasons. App
> code changes due to schema reorganizations related to efficiency are
> roughly only about 5% of all code maintenance I encounter. It is thus
> NOT the low-hanging fruit of changes to target. Your claims don't hold
> up to economic scrutiny. I design my code around change kinds I see
> the most often, and that is NOT one of them. (And often views etc.
> can reduce the impact.)
>
>
>
>
>
>
> Again, these are not necessarily mutually-exclusive. In past debates,
> "complex business logic" to YOU meant graph traversal. I will agree
> that existing RDBMS are not very good at that (but perhaps addable),
> but that does not mean that *only* graph traversal is "complex".
Date: Tue, 04 Mar 2008 18:45:16 -0400
Message-ID: <47cdd101$0$4036$9a566e8b_at_news.aliant.net>
topmind wrote:
>>frebe <frebe73_at_gmail.com> writes:
>
> [...]
>
>
>>Because that has nothing to do with the core issue we're >>discussing. Decoupling components that change for different reasons >>and at different rates is simply good practice,
>
> Like I said before, they usually change for the SAME reasons. App
> code changes due to schema reorganizations related to efficiency are
> roughly only about 5% of all code maintenance I encounter. It is thus
> NOT the low-hanging fruit of changes to target. Your claims don't hold
> up to economic scrutiny. I design my code around change kinds I see
> the most often, and that is NOT one of them. (And often views etc.
> can reduce the impact.)
>
>
>>whether those >>components are business services, database schemas, network protocols, >>GUIs, or anything else. Coupling components that change at different >>rates and for different reasons imposes maintenance costs and makes >>systems more difficult to enhance.
>
>
>
>>>Currently I am developing a web based invoicing and contract >>>management application, for real estate enterprises using the LAMP- >>>stack. The database is obviously a very important part of this >>>application, and MySQL provides excellent performance. >> >> "Excellent performance" is domain dependent. Is this system >>primarily CRUD or is there some complex business logic involved?
>
> Again, these are not necessarily mutually-exclusive. In past debates,
> "complex business logic" to YOU meant graph traversal. I will agree
> that existing RDBMS are not very good at that (but perhaps addable),
> but that does not mean that *only* graph traversal is "complex".
It's not even fair to say that. Quite a few SQL dbmses support transitive closures by one method or another. They each tend to support it a different way with different syntax because the standard doesn't support transitive closures. But those that support it are quite good at it.
> You need to clarify how you are measuring "complex".
I don't know why you waste our time elevating this moron's shit beyond it's real worth. Few of the issues he mentions are even relevant to the choice of logical data model. He just spits out nonsense and demands you make sense of it.
Far better to acknowledge that it's nonsense. Received on Tue Mar 04 2008 - 23:45:16 CET