Re: Mixing OO and DB

> >> >> >> We still have it, and we still use it.  But we also hide it
> >> >> >> from the bulk of the application.
>
> >> >> > What is the benefit with hiding SQL from the bulk of the
> >> >> > application?
>
> >> >>      For one thing, it decouples the application code and the
> >> >> database schema.
>
> >> > And the benefit with decoupling application code and database
> >> > schema, is?
>
> >>      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.

> In addition, when a
> database supports multiple applications, the schema may need to change
> for one application but the others should be insulated from that
> change.  This is common in many enterprises.

Addning columns or tables wouldn't affect the other (old) applications. If you have other changes in mind, please show an example.

> > Yes it is indeed bad design to force every SQL statement to be
> > wrapped inside a method.
>
>      So you prefer littering your code with embedded SQL?  

I wouldn't write exactly the same SQL statement in many different places, in that case I would use a function. But I would wrap every SQL statement in a function.

> This isn't even an issue for the systems I work on.

Why not?

//frebe Received on Sun Mar 02 2008 - 10:47:29 CET