Re: What databases have taught me

From: <>
Date: 27 Jun 2006 04:45:41 -0700
Message-ID: <>

> > > > Another disadvantage is the fact that the number
> > > > SQL statements should be limited
> > > ???
> >
> > For example, a common practice is to only have one update method which
> > updates all columns, regardless if they need to be updated or not. The
> > same practice can be seen with select statments, all columns are
> > selected regardless if you actually need the value or not. You have
> > similar problems with joining.
> What if you have an Employee table which contains a BLOB with the
> employee's mugshot^H^H^H^Hpicture? Updating a set of employees then
> requires you to pass the blob as well even if it's not changed.

I just tell you a common practice in the OO world. I don't agree for the same argument as you provided. If you need to manipulate data, make a update statement that sets the columns you want to change, nothing else.

> > > Does it "have to" ? I've seen a lot of ways to use OO in
> > > SQLDBMS-based applications, not all using "domain objects". So this
> > > can't count as a problem with OO itself, only with how OO is/can be
> > > used.
> >
> > Another problem with OO. Nobody actually knows that OO is. Many OO
> > evangelists would fight until they die before they drop the use of
> > "domain objects". Maybe you can provide links to the definition of OO?
> I fail to see why a lack of agreement over what an acronym stands for
> as in: the exact definition, stops you from applying mechanisms (or
> whatever the f... some people want to call them) in your software
> writing?

But it is a little bit hard to debate benefits and disadvantages with OO if we don't know what we are talking about. The use of "domain objects" are extremly common in "OO applications".

> After all, 'SQL' is also an acronym, and it even had several
> standard versions,

As far as I know there are one standard, ANSI. However the standard is still developing (-92, -99) but I assume that the new versions are backward compatible.

> yet none of the major RDBMS vendors implements these
> standard in full.

This is indeed a problem, but the level of standardization is pretty high.

> So what is 'SQL' anyway?

> Well, a nice definition and
> standard on paper, however in practise you better get your <insert
> dialect acronym here>-SQL manual ready if you want to get things done.

A few years ago I was a member of a team converting a large enterprise application (<500 tables) to support three major database vendors. 99% of the SQL statements are used for all three vendors. We had to drop some vendor specific features, but that is not a big problem.

> > > Strategy pattern doesn't imply subtyping, cf above.
> >
> >
> >
> > ttern.htm
> >
> > It seem to me that subtyping is used. Maybe this is an issue about
> > typeless vs types languages.
> No, the strategy pattern can also be used with plug-in style object
> usage at runtime. Code calls a generic method, that method checks the
> active object which has to handle the call and if it's present it calls
> into that object. You then can swap out algorithms by swapping out the
> object and replace it with another one. Very common in a lot of
> software, like oh, operating systems.

It sounds like function pointers. What extra benefits does OO bring to us?

> > The reason that OO is misused is that nobody really knows what OO is.
> > OO also seem to change by time.
> Of course
> there's no true definition of OO because the _term_ is used in so many
> different ways that to get a unified definition is IMHO impossible.

Isn't that a problem? No formal definition?

> Funny thing is that if you give 3 randomly chosen database architects
> (or whatever the f... some people want to call these people) the task
> to develop the RDM for a big hospital (so you end up with at least 700
> or so tables), you will definitely get 3 completely different models.
> Which one is right? Which one is wrong?

The relational model has a formal definition in opposite to OO. You can also use normalization to validate a model. But it will of course be possible to create different solutions given the same requirements.

Fredrik Bertilsson Received on Tue Jun 27 2006 - 13:45:41 CEST

Original text of this message