Re: How to model searchable properties of an entity

> In a classical database, new properties are discovered over time, but at a
> much slower rate than you are suggesting.
Perhaps, but they're getting more 'classical' by the day.

> In a classical approach, a truly new property is added to the database by
> the DBA using ALTER TABLE ... ADD COLUMN, or in extreme cases CREATE TABLE.
> The DBA is essentially revising and extending the schema so as to evolve the
> schema in parallel with the evolving understanding of the subject matter.
Yep

> The reason OO programmers don't like this is that they don't want to deal
> with a dynamically evolving schema. They would either have to revise and
> extend their programs after they are already in the field, or code a much
> more complex application to deal with an evolving schema.
>
> So they propose a compromise: a static schema that can descibe a
> dynamically evolving subject matter. The problem is that that doesn't
> eliminate the pain. It simply transfers it to someone else. Your admin is
> goin to be a very busy fellow. He's basically forced to maintain in data
> what a classical database would have maintained in metadata.
I don't think I agree on this one. What Dilip is asking for is a way to allow part 'attributes' to be governed by other tables. Something which is 'doable' in the relational sense. Your ADD COLUMN approach will require alot of superflous columns in the part table. If someone wants to add an attribute 'diameter' for a part 'bolt', this would hardly be applicable for the part 'chicken'. I think it's possible to do this properly, the performance question aside.

> It gets worse. A year and a half down the road, performing useful queries
> on this data is going to be like looking for the body of a murder victim in
> a landfill. The container wasn't built with that kind of search in mind.
That's very true. Received on Mon Aug 16 2004 - 16:13:57 CEST