Re: Mixing OO and DB
Date: Tue, 4 Mar 2008 14:28:27 -0800 (PST)
> 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.)
> 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".
-T- Received on Tue Mar 04 2008 - 23:28:27 CET