Re: How to model searchable properties of an entity

From: Laconic2 <laconic2_at_comcast.net>
Date: Tue, 17 Aug 2004 08:58:09 -0400
Message-ID: <KP2dnXSo19rCnb_cRVn-oA_at_comcast.com>


"pstnotpd" <schoenmakers_at_tpd.tno.nl> wrote in message news:cfs9rq$r41$1_at_voyager.news.surf.net...
> > So what sort of meta-data do you want then? I may be missing something
here.

> The meta data describing the part attributes. Maybe I'm using the wrong
> word here. It's more like a template.

data that describes parts is data.

data that describes data is meta data.

I'm not sure exactly what you mean by a template. I've used the term myself in home grown tools I've built to improve my productivity when the client's clock is running. But you may mean something completely different.

>
> B.T.W. I'm not trying to be a zealot here, I just think Dilip's problem
> can be solved because I've done something similar.

IMO, nobody is trying to be a zealot here. Tony doesn't come across as a zealot either.

If I come across as a zealot, it's not intentional. I've seen the solution you outline, after it's been in the field for about a year, and I don't think you fully appreciate the downside of your solution.

Mixing data about more than one attribute in a single column, and then using metadata stored in a nearby column to unscramble the first column has lots of downsides. There are downsides for revising and extending the application, downsides for performance, downsides for the learning curve of new people who have to use the data, etc.

That doesn't mean your solution can't work. It does mean that these downsides need to be evaluated and mitigated before accepting your solution. Received on Tue Aug 17 2004 - 14:58:09 CEST

Original text of this message