Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: How to model searchable properties of an entity

Re: How to model searchable properties of an entity

From: Laconic2 <laconic2_at_comcast.net>
Date: Mon, 16 Aug 2004 09:29:02 -0400
Message-ID: <e6Kdnaa1ydOCK73cRVn-tg@comcast.com>

"Dilip Angal" <dilip_angal_at_yahoo.com> 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.
>

Thank you for clarifying the issues.

By "admin", do you mean a DBA?

If so, I agree with you that that's the person who should control traffic, and add new properties when they are needed, and are not old properties in a new disguise. Having this under a DBA's control is better than having it under the application programmer's control, the users' control, or out of control.

The question is how is it best to exercise this control?

> 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.

In a classical database, new properties are discovered over time, but at a much slower rate than you are suggesting.

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.

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.

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. Received on Mon Aug 16 2004 - 08:29:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US