Re: What databases have taught me

From: Frans Bouma <>
Date: 27 Jun 2006 08:35:31 GMT
Message-Id: <> wrote:

> > > 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.

> > 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? After all, 'SQL' is also an acronym, and it even had several standard versions, yet none of the major RDBMS vendors implements these standard in full. 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.

> > 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.

> > I'm afraid that the problem is more with silver-bullet dealers than
> > with OO itself. If you (ie : a 'generic' you - not necessarily th
> > person named Fredrik Bertilsson) believe that just using a
> > braindead so-called "OO" language and following the braindead "OO
> > 101" tutorials is enough to get any advantage from OO, then you're
> > in deep deep trouble... And you can s/OO/whatever/g IMHO.
> The reason that OO is misused is that nobody really knows what OO is.
> OO also seem to change by time.

        if you apply a given algorithm A, and in 1980 it was called X and today it's called Y, did A change because of that name change? No. Only definition-fetisjists think it's the upmost important issue. 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. However, if you talk to a C++ programmer, a smalltalk programmer and a java programmer and you ask them what OO is, it's likely they declare their language' way of applying OO _the_ way to apply OO. Discussions about that are stone-age old and keep the definition-fetijists off the streets but for the rest it's irrelevant, simply because the theory behind a given pattern P doesn't change which definition of a very generic term like OO you use.

        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? A matter of argumentation and discussion, not something you can test with a hardened testsuit you pull off the shelve. Is RM then an ambiguous technique?

> > OO is just a way to organize code.
> Do you think everybody at comp.object agree?

        I'm certain not everyone agrees, also because it's irrelevant. This isn't comp.OO

> > Ever heard of duck typing, multiple inheritance and multimethods ?
> So far I know, multiple inheritance was skipped in Java because all
> the disadvantages.

        That's Sun propaganda. They just couldn't solve the MI problem in an elegant way, while there is a solution for the problem, see Eiffel.


Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
My .NET blog:
Microsoft MVP (C#) 
Received on Tue Jun 27 2006 - 10:35:31 CEST

Original text of this message