Re: What databases have taught me

From: Bob Badour <>
Date: Tue, 27 Jun 2006 17:22:10 GMT
Message-ID: <6Pdog.2971$>

Frans Bouma wrote:
> wrote:

>>>Strategy pattern doesn't imply subtyping, cf above.
>>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.

With all due respect, the generic method makes all these types subtypes regardless whether one declares them that way or even uses a language that allows one to. They are all subtypes of the union of types defining the method.

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

That wasn't his argument though. If you call one algorithm X in 1980 and   today another algorithm is called X, are they the same algorithm? No.

Thus, speaking sensibly about X becomes extremely difficult. See Date's _Principle of Incoherence_.

[irrelevant tirade against alleged fetishists snipped]

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

I will assume that by 'models' above you mean logical designs. The differences should come as no surprise because they start from requirements and not from a conceptual analysis, which creates the starting point for logical design. Conceptual analysis is 'anything goes' and is well outside the scope of the relational model.

If all three designers started from the same conceptual analysis, the logical designs would be very similar; although, the theory related to higher normal forms proves that in at least some cases there are multiple equivalent non-loss decompositions using project/join. Making those minor differences meaningless.

While a graph of the relations and references among them might look different when drawn by the three designers, they would be pretty-much the same graph.

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

No. The conceptual analysis is the ambiguous part of the example, which is totally irrelevant to the RM.

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

When all the OO proponents at c.o agree on what object means, your response might begin to approach something valid. As it is, your reply was just meaningless handwaving.

[more evasive handwaving snipped] Received on Tue Jun 27 2006 - 19:22:10 CEST

Original text of this message