Re: Principle of Orthogonal Design

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:kO1lj.2507$nK5.335_at_nlpi069.nbdc.sbc.com...

> I think that there are times when it makes sense to 'collectivize' under a
> single predicate, and there are times when it does not. In particular, if
> the individuals represented are just different kinds of the same sort of
> thing, such as is the case with the different kinds of phone numbers, then
> it makes sense to 'collectivize' those attributes that are common to all
of
> those individuals under a single predicate. If, on the other hand, the
> individuals represented are different sorts of things that just happen to
> have the same attributes, then it doesn't. A disjunctive
> predicate--something like, for example, each tuple exemplifies an
individual
> that is an X or a Y, just doesn't make any sense to me. A conjunctive
> predicate on the other hand--for a relation that has multiple keys, for
> example--is not a problem since each tuple would exemplify an individual
> that is /both/ an X /and/ a Y. So if the predicate can be stated so that
it
> is not disjunctive, then 'collectivizing' is to be preferred.
>
It seems to me that you are describing the generalization-specialization pattern.
Am I reading you right?

> > Either way, I certainly find that appealing to notions of "meaning"
> > within formal design recommendations seems to head towards very
> > slippery ground.
> >

Why? If you called it "the semantics of the data" instead, would that make it less slippery ground? Received on Mon Jan 21 2008 - 16:09:16 CET