Re: How to model searchable properties of an entity

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!"
Maybe because of the fact that due to the inheritance relationship of object you can refer to the sub-objects as an instance of the parent class. So if properly designed the complexity of the class hierarchy is not relevant.

> Seems that there is some psychological problem about it. OO
> Programmers feel good if they have all their data in a single "object", no
> matter how complex that objects is and of how many sub-objects it is
> a kind of "object", so they feel uncomfortable if data is spread over
> several rows. Joining these rows together appears a clumsy operation to
> them, though it's logically a simple operation and also not necessarily
> a slow one. (Though it may sometimes be slow in practice)
>
> --
> Rene´ Hartmann
>

Let me please make clear again that I'm neither an OO nor a relational proponent. I'm just interested in the mix and I am not convinced that the 'load of tables' is a good idea. But neither am I convinced that my original idea will turn out very practical either.

According to Fabian Pascal's excellent 'debunking' site an OO type problem like this can be properly done in an RDBMS, so I'm curious how. Received on Wed Aug 18 2004 - 08:28:03 CEST