Re: How to model searchable properties of an entity

From: Tony <andrewst_at_onetel.net.uk>
Date: 16 Aug 2004 07:11:04 -0700
Message-ID: <c0e3f26e.0408160611.70207f65_at_posting.google.com>


dilip_angal_at_yahoo.com (Dilip Angal) wrote in message news:<df683587.0408151804.e7bbb5a_at_posting.google.com>...
> I still don't know how to convince you guys.
> You are all pointing to the process issues that users may give
> different spellings for color.
> I can handle that part by having an admin to create the properties who
> makes sure that the property being added to the part is really
> required and is not used in past by any one in any different context.
>
> But the basic fact does not change.
> I need to keep adding these properties from time to time because user
> communitiy can not decide all of them upfront.

You can add new columns to tables from time to time? Your application could use the data dictionary to determine what columns exist (dynamic SQL).
> Also, I may have 500 such properties and I can have up to 1M different
> part numnbers. This will give you some idea of complexity.
> User may choose, show me all the parts with width 10 inches, and price
> less than $10 and .... can go on for ever. I need to come back in
> resonable time (Reasonable can be couple of seconds)

These cannot be realistic requirements! What user is going to be looking for anything 10 inches wide and costing under $10? Unless they just want something to use for a door-stop, and don't care whether it is a hammer or a toaster...

> Also note that the Search engine techniques used by EBya like company
> works only if these attributes are no updated. If they are ever
> updated, Search engines like inverted index fails miserably.
>
> So, please try to understand my problme and accept it as it is and if
> you have solution to solve it, please let me know.

I think people have understood, and given useful advice. Either you fully model your data (1000 different tables for 1000 different entities or whatever it is), or you don't (e.g. you use the ghastly "EAV" approach). Or you adopt a "middle ground" and fully model the most important, common and stable features (e.g. price - everything has a price, right?), then add some flexibility for the unforeseen (which could be free text, EAV or whatever). Received on Mon Aug 16 2004 - 16:11:04 CEST

Original text of this message