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?
>
> No, I find sticking every little method which consumes customer data
> into the customer entity class a bad idea.

I am a little bit confused here. First you say that you don't belong to the group of people thinking that domain objects should be used. But still you want to create a "customer" class? Maybe we have different definitions of "domain objects". Like everything else in OO, it is hard to debate because every word has different meanings.

> > 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.
>
> that doesn't mean everyone from c.o thinks the same, like not everyone
> in c.d.t. thinks the same about databases (otherwise there wouldn't be
> any discussion ;))

I am not a regular of c.d.t, so I don't know about that forum, but the lack of consensus regarding basic concepts is remarkable high in the OO community. Everything seem to be able to qualify as OO only if you skip the words table and record and name it object instead. You can even make a clone of SQL and name HQL, EJBQL, JDOQL and it will be accepted as a OO concept.

> > The difference between the relational model and the OO model is that
> > the relational model has a formal definition.
>
> you're talking about apples and oranges. it's great that the
> relational model has a formal definition, but a DBA using mysql will
> have to work hard to get it working in practise.

Yes, tuning a database may be difficult, but anyway you will not have to change the application. The logical and physical concerns of a RDBMS are well separated. And normally, if the performance requirements are modest, tuning a RDBMS is not that hard.

> The "OO model" might
> not have a mathematical based definition, that doesn't mean it's
> therefore something not usable. The procedural model also doesn't have
> a formal definition, so you would argue it's also not usable?

That is why I don't use the words "procedural model". Anyway, every programming language has a formal definition (event OO languages). But the problem with the words "object orientation" is the it is so much more than a set of programming languages.

Fredrik Bertilsson
http://frebe.php0h.com Received on Wed Jul 05 2006 - 12:06:39 CEST