Re: What databases have taught me

> > That's my point, most OO people claim that the query result should be
> > mapped to a "domain objects".
>
> Correction: Most 'OO people' (whatever that means) who think Domain
> Driven Design (DDD) is key to success. I'm not one of them btw, and I'm
> sure a lot of others who happen to use an OOPL to write their software
> with also think DDD is overdoing things.

So you agree that making classes like customer, employee, product is a bad idea?

> > > The first stage of decoupling your SQL statement might be:
> > >
> > > RowSet findAllEmployeesOlderThanLivingIn(age, city) {
> > > return execute_sql(
> > > "select name from employees where today()-date_of_birth > ? and
> > > city = ?", age, city);
> > > }
> >
> > Many OO evangelists (including yourself) would argue against this
> > solution, because the caller of findAllEmployeesOlderThanLivingIn need
> > to know about database column names.
>
> Gee, another label. Putting labels onto people isn't going to make
> your own arguments look any stronger, only weaker.

I don't know how many times I have seen people at comp.object refusing to use any solution that doesn't hide database column names.

> In the 'OO world'
> there is also a lot of diversity among how people see the techniques at
> hand:

That makes it very hard to claim advantages of OO, doesn't it? If someone claims that "OO makes change management easier", he has a problem supporting that claim, because he first has to publish his definition of "OO".

> some see it as a way of life and pollute the world with
> zealottery and advocacy no-one but themselves benefits from and others
> see it as a tool to get the job done. In the 'RM world' it's the same
> thing.

The difference between the relational model and the OO model is that the relational model has a formal definition.

> > > I think you'd need this code anyway if the above query was issued
> > > from more than one place. I doubt you'd want to duplicate the
> > > string.
> >
> > If I need to call exactly the same query from more than one place in
> > the application, obviously I would create a function (like I would do
> > anytime the same fragment of code is written multiple times). But the
> > probability of this query being called from more than one point is
> > rather low, don't you think so? The query is tailored for the problem
> > in hand, and you should only make the same implementation once.
> > Otherwise you have duplication on a higher level.
>
> It's not always the right thing to do to make it 1 function. The
> reason is that if you place the query in one place and call it from,
> say, two spots, it then makes these two spots dependent on the
> function's functionality, which thus means that if you need to alter
> the query for one spot, you thus have to realize it will affect more
> spots.

Agreed, that why it may be motivated with identical SQL statements embedded at different spots.

> > > > A very typical scenario is the save method in a DAO. In OO, one
> > > > normally write one save method with one update statement,
> > > > updating all columns regardless they should be updated or not.
> > >
> > > If that's a problem, then don't do that. Update only those columns
> > > that have changed. One would use a special method in the
> > > EmployeeGateway for that purpose.
> >
> > This will give me a lot of update statements that are only used once.
>
> so it's a problem, correct? unless it's an NP, you can find a
> reasonable solution for it. Engineer that solution into your program.
> With meta-data, a simple SQL generator and the data at runtime it's
> easy to produce the query text you need without having to write a lot
> of code.

Or just write an appropiate update statement... There are many workarounds for not using SQL.

Fredrik Bertilsson
http://frebe.php0h.com Received on Tue Jul 04 2006 - 15:08:54 CEST