Re: Mixing OO and DB

Patrick May 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".

You need to clarify how you are measuring "complex".

>
> Sincerely,
>
> Patrick
>

-T- Received on Tue Mar 04 2008 - 23:28:27 CET