Re: How to model searchable properties of an entity

Tony wrote:

> Laconic2 wrote:
>

>>What's wrong with "a load of tables"?  If each table relates to a
>>"proposition"  expressed as a "relation",  then if you have a lot of
>>propositions,  perhaps you ought to have a lot of tables.
>>
>>It continues to baffle me why people think that terabytes of data is "not
>>complex", but a hundred tables or so is beyond human comprehension.  But
>>that probably reflects the fact that I'm closer to the "data centric"
>>mindset than I am to the OO mindset.

An important difference would be: the hundreds of tables, and so the complexity, are by default exposed. The subclasses (and complexitiy) are hidden.

> I think one possible issue is this requirement to perform queries like
> "select everything that is blue". If we have 1000 different product
> types, and of those 500 have a colour attribute, then either (a) we
> need a supertype table that pulls together either all 1000 product
> types, or just the 500 that have a colour, or (b) we need to UNION
> together 500 tables.

... and hide the base tables.

> Of course, this is only an issue if such queries
> ever make any sense: e.g. maybe someone with a colour-coordinated
> kitchen might want to see all kitchen equipment that comes in blue.

There will be very weird searches possible. Received on Wed Aug 18 2004 - 11:07:00 CEST