Re: How to model searchable properties of an entity

Laconic2 wrote:

> Rene Hartmann wrote:
>

>>I am also wondering why many people feel so unformfortable about
>>having may tables. For most OO people, it is quite natural to have
>>many classes, and to have "complex objects" which consist of many
>>"sub-objects". But when it's about a relational model of the data, 
>>they say: "Oh look, how complex and clumsy this is - the data is
>> spread over so many tables!"

Different? From what? I guess you meant from thinking in processes or from object thinking, and where they are not the same I'll assume object thinking.

> Abstraction, in general, is the deliberate omission from consideration of
> certain details, that are seen as immaterial to the matter at hand.
> Basically, the human mind can't cope with "reality" unless some details
> are omitted.

That is the common ground - a good place to start (re)building the framework, I think.

> There is a special form of abstraction in the OO world called,
> "encapsulation". Most readers will already know what encapsulation is, so
> I won't try to define it. But basically, "encapsulation" facilitates
> abstraction by hiding information that ought to be hidden, for some reason.
> If that information changes later on, the consequenses are contained
> precisely because the information was hidden.

Encapsulation is one form of information hiding in order to modularise. The basis for modularisation in OO is somewhat anthropomorphic: the system is thought of as pieces of data with behaviour. These pieces interact. They live within running programs.

> Data Centric people (like myself) go for a different special form of
> abstraction called "data independence". Basically a query's results (and to
> some extent it's performance) should not depend on features of the data
> unused by the query. Thus, if a query pulls last names, first names, and
> phone numbers out of a database, it should work the same if someone comes
> along and changes all the zip codes from 5 digits to 9 digits.

> Encapsulation and Data Independence both protect systems from what has been
> called "the ripple effect". (You throw a rock in the middle of a pond, and
> pretty soon, there are ripples all over the surface. ) But they do so in
> such radically different ways that each of them looks counterproductive, if
> not downright dangerous, to the other camp.

You speak of camps - I admit I recognise them. Yet - both ways of thinking are necessary to develop a working system. Data lying around uselessly or objects having significance only within one program-lifetime don't count as a useful system. Received on Wed Aug 18 2004 - 00:01:49 CEST