Re: Mixing OO and DB

On 4 Mar, 22:52, Patrick May <p..._at_spe.com> wrote:
> >>      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.
>
> > Since you keep the original column, no existing SQL statements would
> > break. No existing business logic has to change. Only the code that
> > want to use the new redundant column need to change.
>
>      Exactly.
>
> > Wrapping every SQL statement in a function would not give any
> > advantage at all.
>
>      Decoupling the SQL statements related to the now denormalized
> schema from the application code that invokes them has significant
> value.  The change can be made and tested in isolation and the
> application itself doesn't have to change at all.  When the new
> version of the component containing the SQL code is deployed, the
> application simply runs faster.

If you create a new table, no existing SQL statements has to change. Your method doesn't provide any value. If you want to keep claiming that your method provide any value, you have to demonstrate it. Otherwise it is just nice words.

> > One could also argue whether your denormalization would gain any
> > performance at all. Why don't you publish the schema, indexes, query
> > and let the guys from c.d.t, evaluate the possible performance gain.
>
>      Because that has nothing to do with the core issue we're
> discussing.

It was you who introduced "denormalization for performance" as an example for supporting your claims. If it has nothing to do with the core issue, you should have used another example.

>  Decoupling components that change for different reasons
> and at different rates is simply good practice, 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.

First, one have to show that they do change for different reasons.

>      Your requests for specific schema examples are a red herring that
> would take this conversation down a rathole of different design
> alternatives.

It would make us able to validate your claims.

> >> Have you never experienced these kinds of changes?  They happen
> >> often enough in my, and others, experience that the decoupling
> >> provided by OO techniques has proven useful.  Despite what some
> >> relational proponents think, developers don't come up with these
> >> approaches because they dislike or don't understand relational
> >> databases.  They do it because they're trying to solve real
> >> problems.
>
> >>      Consider a regulatory change like Sarbanes-Oxley.  Companies
> >> need to add additional monitoring rules, but they have existing
> >> applications in place that they don't want to change any more than
> >> absolutely necessary due to the high cost of doing so.  The
> >> applications can be encapsulated to work without change within a
> >> different workflow.  That workflow requires additional information
> >> in the database, in particular more detailed audit information and
> >> finer grained tracking of individual steps in the process.  This
> >> results in schema changes but does not change the behavior of
> >> existing applications.
>
> > Still no schema examples....
>
>      Still waving that red herring around.  Have you or haven't you
> ever experienced these kinds of changes?

The questing is if the scenario above the case only the schema to change and not the application ("change for different reasons"). Without knowing the details of your example, it still looks obvious that both the schema and application need to change. That makes your example useless in this discussion.

> >> >>      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).
>
> >> > This is all very nice words, but at least we need some examples
> >> > to verify it.
>
> >>      Particular schema examples will not help.  
>
> > They will not help you keep making unsupported claims.
>
>      My claims are supported by numerous arguments at a higher level
> of abstraction than schema details.

Since our discussion is about schema that changes, but applications which doesn't. Some details about those schema changes would be interesting.

> >> Either you've experienced this or you haven't.
>
> > The question if your method is a good one or not, not if the
> > scenario is experienced or not.
>
>      No, the question is whether or not you've experienced the kinds
> of problems that tight coupling of logically disparate components can
> cause.  

Since we don't agree whether the components are logically disparate or not, we have to start with that issue.

> The difficulties that arise are very real.  The decoupling
> techniques weren't created just for the sake of coding.

The reason OO people like to "decouple" the SQL statements is: 1. OO languages doesn't have good support for embedding SQL. 2. OO like to model data as a network graph, in opposite to the relational model.

> >> If you haven't, you should at least be able to understand that
> >> these kinds of environments do exist and these kinds of changes do
> >> take place.  This is not a discussion about particular schema
> >> changes, it is about the value of decoupling.
>
> > It is a discussion about whether wrapping SQL statements will help
> > handling schema changes or not. Without knowing what kind of schema
> > changes we are talking about, any evaluation of your method will be
> > impossible.
>
>      Not so.  Application logic and database schemas change at
> different rates and for different reasons.  

This doesn't become true, just because your repeat it ten times every post. Try to spend your time with supporting the claim, instead of repeating it.

> >> They've personally experienced the costs of doing so and don't want
> >> to go through it again.
>
> > Mainstream OOPLs has very poor support for embedding SQL, that's why
> > the cost migh be high. Older non-OO languages has much better
> > support for embedding SQL.
>
>      So basically you're just suggesting that OO techniques should
> never be used?

No, you have to write SQL statements as string in your host language, if your host language lack support for true embedded SQL.

> >>      What kind of systems do you build?  Perhaps we can find some
> >> common problem domains that would make this conversation more
> >> productive.
>
> > 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?

If you have a definition of "CRUD" and "complex business logic", I would be able to answer the question. For example, producing an invoice can be pretty easy with a good database design. With a bad database design it (the business logic) quickly becomes rather complex.

//frebe Received on Wed Mar 05 2008 - 07:20:57 CET