Re: How to model searchable properties of an entity

"Laconic2" <laconic2_at_comcast.net> wrote in message news:<_sGdndMfcq9Xi7_cRVn-qQ_at_comcast.com>...
> 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.

I couldn't agree more. And if the issue IS coming from an OO perspective, than how is having hundreds of classes and subclasses good while hundreds of tables is bad?

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. 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. Received on Wed Aug 18 2004 - 10:51:48 CEST